That's a pretty big decision with a huge impact on many levels. Was the FWT and the release manager included in that decision? Such a step needs careful planing and discussion in my opinion. (Sorry, if my points already have been taken into account, I missed quite a few fwt meeting lately)
@tisto At the FWT, we are already discussing Plone 5.1 PLIPs. The decision to prepare the 5.1 branches was even done short before the Plone Conference last year, but we waited until we need these branches: Framework team meeting minutes 2015-09-29
Now the time has come.
I was under the assumption that this decision should be made by @esteele and not by the framework team. The responsibility of the framework team is to review PLIPs, not to make a release schedule or cut CMFPlone branches. I know we have different opinions on that. Though, if we change our policy and broaden the scope of the FWT responsiblities, we should do that in an open and transparent way.
Maintaining two Plone 5 branches has a cost. We need to keep track of changes, backport fixes, be careful when making releases, etc. This did not work that well in the past, we even completely abandoned branches that were cut and could not be kept in sync. It is always easy to cut a branch, but hard to maintain it in a proper way.
Therefore I would recommend to always cut the CMFPlone branch as late as possible to keep maintenance cost low. If we have enough PLIPs ready to be merged to make an alpha release, fine, let's cut the branch and try to make a 5.1 as soon as possible. If not, let's keep the PLIP jobs up-to-date and wait to not waste too much effort.
Going through the PLIP spreadsheet I currently do not see the immediate need to cut a branch. I could be mistaken though.
Regarding the testing team and the CI setup we will need more hardware if we want to run four instead of three different versions. I don't see how our current setup can scale on a sprint or when making releases.
Also @esteele was involved as you can read in the minutes I linked above. And if you look carefully at the minutes and at the PLIP spreadsheet you will notice that all unmerged PLIPs are already at the 5.1 spreadsheet.
Also if we want to stick at least roughly to semantic versioning (and I propose to stick more strict in future): the upcoming PLIPs are features which need a version bump.
Sorry, @tisto, but as you bring up this here I have to write this here too: It is ok if one of us is short on time and can not participate at the FWT meetings. But please don't irritate people reading this thread and make them feel Plone badly managed. This is not the case, but the opposite is true.
Plone moves forward, carefully and transparent communicating the changes and making a difference between features and bug fixes. Semantic Versioning is an important part of this culture of well defined communication and needs version bumps at some point - and we decided we are there now.
@jensens do you have an idea of current blockers for a 5.1 release? seems to me that all the issues listed in the minutes of the last FWT meeting are enhancements, but there are a bunch of bugs open in GitHub right now and I'm specially concerned with the ones related with the toolbar.
I share your concern regarding testing, and specially with how many parallel jobs are we able to run.
OTOH if we want to use semantic versioning that's just how it is, see setuptools for a, maybe fully strict semantic versioning.
What probably needs to be discussed at the next FWT meeting together with the release manager would be about the support policy. By releasing Plone 5.1 do we drop support for 4.3? and as soon as 5.2 is out do we drop 5.0 already? Or we only support the last major version (4.3) and one or two minor versions (say 5.2 is out and 5.1 and 5.0 are still supported, but as soon as 5.3 is out 5.0 support is dropped).
And back to the testing point, but more from the development prespective, we need to put somewhere crystal clear, @svx was asking for that as well, which Plone version any branch of any given core package is targeting.
So by now only p.a.vocabularies master branch is 5.1 only as that's the only branch merged of PLIP 1342:
So something like a list on each package (on each branch) the README's top saying:
Plone versions supported on this branch:
To support version X.Y please use profile YZ
To support version Z.U please import xxx.zcml file
Could be enough? And keeping that list in sync with setup.py's classifiers would be great, so we could extract more exact numbers from pypi and give some guidance to collective/external packages.
We could also improve mr.roboto to add a warning comment to a pull request that targets a non master branch (pointing to which Plone version that pull request will end up, i.e. "Your pull request, when merged, will be part of a Plone release on the 4.3.x series").
If some automation is called for, you can get the classifiers from setup.py like this:
$ python setup.py --classifiers Framework :: Plone Framework :: Plone :: 4.3 Programming Language :: Python Programming Language :: Python :: 2.6 Programming Language :: Python :: 2.7 Topic :: Software Development :: Libraries :: Python Modules
But of course, if you want to use this information to update README.rst and this file is included as long description in setup.py, then you have a circular dependency...
plone.releaser could do something helpful here, but likely the best we can do there is take the Plone classifiers from this list and grep the README.rst for occurrence of in this case 4.3 and show those lines to the one doing the release and asking if that seems okay.
Just a heads up: jobs have been created in jenkins.plone.org (see commit) but mr.roboto so far does not create the fake commits on 5.1 branch, which basically means that it's not safe to push changes meant for Plone 5.1 right now.
You are welcome, although I must say that it's been two days of going to sleep after 2AM to fix and put everything in place...
So next time, please pre-announce and let's have some time to prepare things, because creating a branch is quite simple, putting all the configuration for jenkins/mr.roboto and what not, not so much...