As planned and in order to get further with Plone core development and waiting PLIPs, I branched buildout.coredev to 5.1 and set it as default branch.
Also Products.CMFPlone master targets now 5.1 and a new 5.0.x was created. 5.1 provides a new zcml feature "plone-51".
@gforcada and the testing team: Is guess there is minor adjustment in the test setup needed to reflect this?
Yes, I guess we want to create a pull request job for it and core jobs as well.
mr.roboto (for the fake commits on coredev will need to be adjusted as well).
I will try to work on it at night if no one is faster than me 
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)
the decision was made at last FWT meeting: 5.1 after 5.0.3
@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.
The decision was made with care.
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.
Plone is powered by the community and we steadily get a stream of Pull Requests with bug fixes and merge them.
I'd really love to get more of them!
Unfortunately it is out of scope of the Framework Team to decide which bug is fixed next by whom.
We are just starting with 5.1. There are some Pull Requests in progress or ready to merge. First 5.0.3 (currently RC) will be released but we do not plan another 5.0.4 (except for urgent reasons).
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:
Compatibility
Plone versions supported on this branch:
- 5.1
- 5.0
- 4.3
Compatibility notes:
- 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.
I will PLIP this later today.
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").
3 posts were split to a new topic: New/more Jenkins Nodes
Hey my two cents 
Last Plone versions branches where created by the release manager, because in my opinion its his/her job and we delegate the responsability to him/her.
4.3 : 7bba8a90cce7953f2a1da325158f7ace79c67706
4.4 : ceaee7461daa51eca354d80456beec34c6ea11e1
When this releases branch on coredev.buildout were done was because eggs where already released and tested on older versions of Plone. In my opinion this hurry is not good. But its my opinion.
Instead, we could enforce trove classifiers to be used to indicate the compatible Plone version.
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.
And now you can forget about my previous message. Plone 5.1 is ready to be tested, and so far is still green
Thank you @gforcada!
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...