From this year we will start to development NexT v7. And NexT v6 will not be cutted-out for now. Instead of this, we will continue maintenance for version 6 with simultaneous development of version 7.
What changes planned in that versions? Good question, here they are:
- Development (v7) mean → all bugfixes, optimizations and features will be added in this version.
- Maintenance (v6) mean → all bugfixes and optimizations (partially) only will be added in this version.
As we can see, v6 will be more stable version, unlike of v7. If someone want more stability with less features, recommended to use v6 without any fear about no maintenance for this version in the future.
There are several globally targets for NexT v7 changes planned:
- Replace all Nested Strings by Template Literals. This bring to code more readable (example: #557)
- Cut out all possible 3rd-party libraries for provide minimum weight and maximum generation speed
- Targets, described in NexT v7.x Roadmap.
All last year there are no problem with branching model management. All was simple:
- We had master branch, which at the same time was development and production branch.
- Changes created in separate temporarily branches were merged into master branch via pull request's.
- Once per month we made tag releases from current master branch.
It was when NexT development came with single version. For now, we must support multiple versions: v6.x and v7.x, what bring some complicated as for maintainers and for users too.
Last several days I thinking a lot about this and it seems the right way was successfully founded. And before understand my decision, let's see on all articles I finded.
- A successful Git branching model → https://nvie.com/posts/a-successful-git-branching-model/
- Cactus model → https://barro.github.io/2016/02/a-succesful-git-branching-model-considered-harmful/
- OneFlow model → https://www.endoflineblog.com/oneflow-a-git-branching-model-and-workflow
- A stable mainline branching model → http://www.bitsnbites.eu/a-stable-mainline-branching-model-for-git/
So, lets comment this models:
- A little bit complicated for development.
masterbranch keep only releases versions, but we already have tags once per month. And I read some negative responses about this branching model.
- Only one thing let me get to doubt: rebased branches. Yes, on local branches anyone can do what he's want, but we talking about remote branches, how we will working with them. This model is good, but need some changes to use it.
merge --no--ff– only with a little difference with allow to minimize merged commits history. Anyway, history will not linear.
- So, this is similar to our model, with except – releases created not only under the tags, but under branches too. As I understand, branches serve for temporary maintenance multiple software versions. And this model exactly what we need! With some changes, of course...
As described above, most liked branching model is 4. But need to make some changes in this model to be sure with NexT compatibility. Let's write in order:
- We have master branch, which at the same time is development and production branch (as was before).
- We turn off merge and rebase buttons to provide to all pulls be squashed. This will allow to get single commits from any features / bugfixes or optimizations.
- We have separated v6.x branch and copy only bugfixes and some optimizations there via cherry-pick single commits, which previously we provide.
- Once per month we will make tag releases from current master branch (it will be NexT v7) and from v6.x branch (it will be NexT v6).
Only one question here: do we need to have separated v7.x branch to advantage at most cases stable releases?
To provide linear history, there is no need to update branch from master!
When we push this button, it's mean we will
master branch into current
bugfix branch. As a result, history will not linear. So, no need to push this button.
By default, GitHub merge pulls (Merge button) with
-no-ff option. What's different with
As we see, it's like
rebase, but with a little different. What's different?
rebase – rebased branch will be at the head from parent branch. It's like snake-game, but with separated sections.
merge – we get same at the result, but both branches will be in the head.
In simple words: you can copy any commit from any branch and paste this commit to the head of any another branch. In this picture commit F (feature-1) from feature branch was copied into G in master branch with this feature.