Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Sonata version management #3053
@rande As we discussed, you said that branch management was failed and should be reviewed.
So I decide to make a proposal about this.
I make it as an issue on SonataAdminBundle cause this is the most viewed repositories and any contributors feedback would be appreciated.
Versions tags and branches
We should enable a road-map for repositories versions. This will help a lot user to know which version to install and contributors to know where they must propose their PR.
I propose the following schema:
Here, a example table with some sonata packages, based on next stable release (e.g. 3.0 for admin):
Feel free to add package you think important by comment, I'll merge it on this table.
Starting new stable version, the branching system should be done like Symfony team does:
All minor tags (e.g. 1.2 => 1.3) MUST be BC according to semver: http://semver.org/
If someone propose a PR with BC break that cannot be resolved, let's wait for the new major release.
I propose to specify which version is related to the changelog message.
I think milestones should be used at least for next version preparing. We can start by opening a
This will drastically simplify issues and PR management. In addition, if a BC breaking PR is coming and new major version is not for now, this could be added onto a milestone too.
Thanks for reading
I think this is a great idea and it is something that is currently missing indeed. In my opinion a lot of people are currently having trouble with Sonata due to missing knowledge about bundles and versions they can/should use.
I do have some questions/ideas about some things in the proposal:
Actually no. Bundles are separated so if one of them has no need of new minor or major version, it will be left as is. As you can see in my table, versions are different across bundles actually.
Yes. Old not mergeable branches will be simply abandoned. But it wont necessary start with a new major version but with the next stable. In example, for SonataAdminBundle, the starting point will be on
For bundle having stable version on not new minor/major version on progess, the current version will be the starting point. It's the case of SonataCacheBundle.
Well, that's an idea. To be honest, I got the same for a while. But for doing that, we have to make the same logic as Symfony, e.g. moving all source code on one repository like
That will cost huge efforts and could be painful. BTW, I haven't enough knowledge of all sonata bundle to know if it's feasible.
I think we should leave this as is for the moment and start a new discussion with @rande about it when we'll got a stable branches and versions management.
@Soullivaneuh thanks for the response. All answers are pretty clear to me. For my last question, I understand this would be very hard and might not be interesting. (Even though I believe that this has many advantages too)
I do believe if we don't to this, we got to have a good documentation page about versions. When I started with Sonata, I guessed I had to use the same version numbers (2.3 with 2.3 or 2.4 with 2.4) where possible, while this is not always true and some bundles have entirely different version numbers.
How I believe this idea will go, there will be new versions of bundles sooner than before, which will mean it will be harder to know which versions work together. Or should you just only use stable/nightly/legacy bundles together, and don't mix them?
Also a small note, you have some typo's in this issue. It states a few times
It's interesting. But have we have more urgent issue to solve at this moment: versionning.
BTW, some sonata package like
As I said, this will be a good start for a another discussion IMO.
I agree. I'll propose it on a PR for
I don't understand the point of your question, sorry. :-)
What I meant was, when there will be a nightly/stable/legacy version for each bundle. Does that ensure a user should use the same versions combined, or is it still possible to mix them.
Does that mean I can only use AdminBundle 2.5 with CoreBundle 2.4, or is it supported to mix the AdminBundle 2.5 with CoreBundle 2.3 (or any other combination of different types of stability).
You shouldnt really need to take care about this, since dependency management is what composer does for you. If you install the AdminBundle in Version 2.4, it will automatically install the required Version of the CoreBundle.
As for the general idea of this thread, you have my +1 :)
@Brainshack just answered right:
In addition, minor version should not be BC break, so you'll be able to upgrade easily.
A couple of questions / comments:
I'd say that features which don't break BC could be applied to an older version, and merged through the later versions. Symfony does this
But overall, yes, a massive
A note on the README. Generaly,
Exactly, but on a minor (e.g. 1.X), not a patch (e.g. 1.0.X).
Jun 16, 2015
and it would be great to be more careful about semver. the changes between SonataAdminBundle between 2.3 and 2.4 are so big, e.g. jquery inclusion and the base admin classes method signatures changes alone would imho have been enough for calling it 3.0.
there should not be a new major version every 3 months, but if its needed, lets not hesistate to do one. otherwise keep BC and record issues for the next major version
I which part?
Agree. But I think this is too late for 2.3. We will make a good start with 2.4.
This is exactly why I proposed milestone usage.
This was referenced
Jul 1, 2015
Is this proposal accepted? If so, what are our first steps? Should we open an issue / PR for each of the bundles to ensure they all declare their dependencies correctly?
If not, what do we do to make it happen? It would be a huge improvement to sonata in general.
Not yet, I have to talk about it with @rande.
I'll open a first PR on sonata-admin for tests and discussion. Next, I'll apply it on all bundles. Maybe a common repositories for contribution doc would be nice too.