Ckeditor5: Introduce the stable branches

Created on 9 Nov 2017  ·  13Comments  ·  Source: ckeditor/ckeditor5

Currently, we're pushing all the changes to master which, therefore, at a given point in time may contain:

  • an unstable version of the code,
  • work-in-progress stuff,
  • breaking changes comparing to the latest release.

This means that two kinds of situations happen:

  • The official documentation gets out of sync with what's on npm. Right now, what we have on docs.ckeditor.com contains updated guides and API docs after refactoring that we did, but that code is not yet published on npm and won't be published there for some time.
  • We need to release a hotfix for one of the packages but its master contains changes which depend on changes in other packages... so we can't start the hotfix on master – we need to start it from the latest tag.

So, we need a more stable branch where none of the 3 things that I listed above will occur. There are multiple branching models for Git and there are at least two models which might work for us:

  • master which contains the stable code and hotfixes and dev which contains all latest changes (used daily for development),
  • master which is used for development and stable which is used for hotfixes and can be released at any moment.

I prefer the second option as master is what developers cloning the code will be interested in (you clone the code to use the latest dev version of it). stable will then be able to contain hotfixes and documentation fixes and improvements (for the latest release).

TODOs and notes:

  • Create this branch in every repo.
  • Make our release tools aware that they need to update stable after release. They could also verify (before the release) that stable is correctly merged into master because every change that we'll do on stable should be ASAP merged to master.
  • Make the builder for our docs.ckeditor.com use the stable branches. Nightly docs will still use master.
discussion improvement

Most helpful comment

I am for master/stable because I am used to pushing stuff to master. I would be the first one to accidentally push something to "stable" master.

All 13 comments

They could also verify (before the release) that stable is correctly merged into master because every change that we'll do on stable should be ASAP merged to master.

Hm... this is not true if we're releasing a hotfix. Perhaps we'd need a flag which switches off this check and also makes sure that other things won't blow up (changes to ckeditor/ckeditor5, builds, etc).

BTW, CKEditor 4 uses master and major where master contains non breaking changes. This means that two code lines need to be maintained together. It'd be an overkill for CKEditor 5 (especially now) where half of the changes are breaking. In CKEditor 4 it looks a bit different and the team switches between master/major work less frequently.

My vote for master / develop - just because I'm used to it on some private projects.

I'm also OK with master and develop. I'm familiar with this names because I was using gitflow in the past.

:+1: for master / develop.

I understand that this may be more common. But how will it work with our multi-repo architecture? Perhaps... we can have different mgit.jsons in ckeditor5#master and ckeditor5#stable.

However, that basically means more work if you want to check out to the latest dev version. That's why I'd rather prefer (if that's not something completely confusing and uncommon) the master/stable configuration.

@Reinmar maybe some handy mgit command/config? I'm asking since I don't use mgit that much (I can switch all ckeditor5 & packages branches from IDE).

Mgit offers much more then checkout but it isn't topic about mgit I guess.

I understand that this may be more common. But how will it work with our multi-repo architecture? Perhaps... we can have different mgit.jsons in ckeditor5#master and ckeditor5#stable.

However, that basically means more work if you want to check out to the latest dev version.

master/stable 👍

If master/stable needs less effort than develop/master then master/stable is fine.

I am for master/stable because I am used to pushing stuff to master. I would be the first one to accidentally push something to "stable" master.

@scofalik don't worry github branches can be configured to protect some branches from direct commits.

All done here.

Was this page helpful?
0 / 5 - 0 ratings