New Plone 5.1 branch

@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.

1 Like

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 :stuck_out_tongue:

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.

1 Like

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 :slight_smile:

1 Like

Thank you @gforcada!

1 Like

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...

I'm sorry for that!

Is there a bunch of commits for reference, so that next time some work can be saved?
At the FWT we're discussing faster minor releases following the semantic versioning scheme. I expect more minor releases coming this year.

I don't mind that, the more the better, the problem that this thread was a post-announcement rather than a pre-announcement.

And yes of course for 5.2 it will be easier/faster but I (others from the testing team) may be on holidays, etc etc

So some planning and guidelines would be best, rather than marching forward not matter what and fixing things afterwards.

And as @tisto was pointing, usually Eric was doing it with enough time to put things going on. If we had the time to discuss that within the release team, at least I could have raised the concern of having the CI setup ready to go.

Bottom line: we need to document and make sure that anybody involved in this process has a heads-up and can be involved in the timing.

I understand that, but my other concern is try to avoid the mistakes of previous releases when we tried to do too much and that complicated the whole release and adoption processes. I would prefer to have many small releases adding a few well-discussed features and fixing as many bugs as we can.

may we consider that list of features the one from the FWT minutes listed before?

and I just want to be clear before someone came here to tell me the obvious, that I'm neither the release manager nor a member of the FWT: the whole process is way too important to leave its decisions in the hands of a few core developers, no matter how good they are; everybody interested should be able to express opinions on the topic.

we need an updated roadmap.

1 Like

I've been swamped this week and haven't been able to weigh in. The Framework Team did decide to move on to 5.1 during our last meeting, but I wasn't under the impression that it was something that was going to happen right now, otherwise I would have set it up myself.