Currently, we're pushing all the changes to master which, therefore, at a given point in time may contain:
This means that two kinds of situations happen:
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:
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.stable branches. Nightly docs will still use master.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.
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.