I've noticed couple weeks ago that there are a number of production branches for Products.CMFPlone , each targeting a different version of Plone. Two of which, I've been constantly working with. For the last two weeks, I've been updating both the master branch and 5.0.x branch, mainly because I believe the next release of this package will be based on the 5.0.x branch, while master should always have the latest changes. The master and 5.0.x branches are different due to the need of
Plone.CMFCore.indexing and other dependencies that are found in the master. Therefore, simply bubbling up the changes is a bit of a hassle especially when using git rebase.
What I want to know is, should I continue to update both packages or can I update only the 5.0.x branch?
It's a bit more complex, but at the same time more simple:
Plone has 3 active branches (in buildout.coredev):
4.3 is an LTS release, which means that only bug fixes and minimal changes are expected there. No new big/breaking features should be expected there.
5.0 is the current latest stable release where small/medium new features and bug fixes are expected.
5.1 is the development branch where breaking changes can be safely landed.
So in short: if you want to land new changes, the safest bet is to do it on 5.1. If the change is small or incremental, it could make sense to backport it to 5.0 as well. Finally, if it is really minimal it could be even backported to 4.3.
As for which package branch is used for each plone release? You can find it either here http://jenkins.plone.org/roboto/branches or directly on buildout.coredev looking at the
sources.cfg of each branch.
I hope I've explained myself properly if not, let me know.
@gforcada and 5.1 is actually the master branch, correct?
Yes, mostly it is always master. But to be extra sure always check buildout.coredev sources.cfg
I think we need to clarify this; Plone follows (or try to follow) Semantic Versioning guidelines which means in short:
Given a version number MAJOR.MINOR.PATCH, increment the:
MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards-compatible manner, and
PATCH version when you make backwards-compatible bug fixes.
so, we don't expect breaking changes at all in Plone 5.1, but in Plone 6 only.
also, note that because of the current situation with the resource registry, the 4.3 branch has been including some backported features (something similar to what is happening in Python 2.7 branch).
as we are a small community and lately we have found some issues on new releases of this branch, I would love not to continue with this practice at all, and put all our efforts on making a final release of Plone 5.1 first and then continue the work to fix all broken stuff in Plone 6 as soon as possible.
Here is what came out of PLOG discussions about Plone 5.x and 6.0:
Yes, you've been quite helpful on this topic. Thank you for your explanation.
Btw, Is there any official documentation or quick notes for this?
@gforcada , the upgrade step for CMFPlone should be added to plone.app.upgrade, right?
Can you provide me with the steps to be taken to update the resource registry or create an upgrade step? I need to add a new static resource to be available on an existing site.
Pull Request 126 contains the files I edit to make js-contextmenu available in the resource registry for existing sites. Did I do it right?
@b4oshany yes to p.a.upgrade
As for the steps to create such an upgrade step, you can either look at the git log or past pull requests for some other examples or as @thet which is more literate about that than me