Create version branches that correspond to Symfony version

[ribeiropaulor]

I can see from the comment in the releases that you plan to update the bundle to support Symfony 2.4.

Although, ideally, we'd all have our projects updated with the last available version of Symfony2, that's usually not possible.

We should create corresponding branch versions that could be still updated. This way would still be possible to maintain the bundle updated for former Symfony versions.

I'm not saying that you have to main many versions, but, as this is a small project, that should be possible, with help from others devs too, maintain those versions at least compiling.

If this bundle already works with SF2.1 and for each SF version after was introduced a BC, we should have the following branches.

2.1
2.3 (for SF 2.2 and 2.3)
2.4

This way critical issues should be fixed in all branches.

Also, you could adopt a standardized way to choose the version tag. First the SF compatible version, then the bundle own version.

v2.1.1.10 - from branch 2.1, compatible with SF 2.1, bundle version 1.10
v2.3.2.13 - from branch 2.3, compatible with SF 2.3, bundle version 2.13
v2.4.1.0 - from branch 2.4, compatible with SF 2.4, bundle version 1.0

New features would be implemented usually only in the latest branch. And the modification to previous branches would be made for eliminating bugs or contributed by a developer that needs some modification that do not cause BC.

What do you think?

[sheeep]

Hi @ribeiropaulor and thanks for your input!

I generally support your idea of maintaining several branches for different versions, even though they introduce an overhead for even the simplest merge. In my current understanding you would base a bugfix pull request against the lowest version where the fix should be applied and the repo maintainer would then cherry-pick the commit(s) and merge it to all the relevant branches above. Do you have any experience in maintaining multiple branches including pull-requests? If so: am I missing something here?

However: Support for Symfony2.1 was dropped when introducing version 1.0.0 of this bundle 5 month ago. I currently can't think of a reason to re-introduce support for 2.1 as the release schedule states an EOL for 11/2013. This repository is currently tested against version 2.2 to version 2.4 of the Symfony Framework and has not introduced a backwards compatibility break that would have implied a version bumb or a branching model like the one you mentioned. (Actually I just can't remember any, but correct me if I'm wrong. =)

v2.1.1.10 - from branch 2.1, compatible with SF 2.1, bundle version 1.10
v2.3.2.13 - from branch 2.3, compatible with SF 2.3, bundle version 2.13
v2.4.1.0 - from branch 2.4, compatible with SF 2.4, bundle version 1.0

This bundle follows the rules of semantic versioning, a concept which got highly adapted due to it's credibility. I'm afraid I can't drop that. But take a look at the FOSUserBundle. They just map the bundle versions to the Symfony versions in their readme file while following semantic versioning.

My suggestion would be the following: We proceed with our master branch and the tags until we introduce a BC-break which would exclude developers using a former (but supported by now) Symfony version. We then create a version branch and maintain both the one created and the master branch.

How does that sound? :)

[ribeiropaulor]

Hi @sheeep!

well, I overlooked that the bundle does not support SF 2.1 anymore. Sorry!

Your suggestion sounds good indeed.

I maintain a bunch of repositories that are SF2 bundles. I'm trying to figure out myself the best way to keep them in sync with SF2 versions. Until now I haven't thought about it with such clearness. I'll try your suggestion with some of them.

BTW, about the testing stuff. Do you run the bundles test without setup a SF2 project? Would your /Tests/bootstrap.php do all the magic needed? Bundle testing is another subject that still waiting for a silver bullet in my dev env.

[sheeep]

BTW, about the testing stuff. Do you run the bundles test without setup a SF2 project?

Yes of course. :). You can basically just clone the repo, install the vendors through composer and run the unit-tests with phpunit.

Bundle testing is another subject that still waiting for a silver bullet in my dev env.

Yep, me too. It seems like everyone is doing it a little bit different, but you asked, so I'll do my best to clarify this.

The bootstrap.php checks for installed vendors and dies if not available. The phpunit.xml.dist in the root directory of this bundle registers not only the bootstrap file but an AppKernel with which I can easily test the controller parts of this bundle. This kernel only loads the necessary bundles to run the tests with. You still need some framework configuration, which is placed in App/config. (Not sure, but I think this could be simplified in some way or another). After creating the kernel, phpunit is ready to run the configured tests.

If you try to understand the testing workflow of a bundle, it's always a good idea to check the .travis.yml file, which basically sets up the bundle to be tested by an automated worker. In some occasions you'll find some more steps to set up the test suite or software needed to run the test.

I hope this clears it up a little bit.

post scriptum: If you want to dive into bundle testing, I'm always happy to receive pull requests in that manner ;)

[ribeiropaulor]

Thanks for the explanation, @sheeep !