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.
Versions Difference
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.
Objectives of Version 7
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.
Branching Models
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.
master branch 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.
- Again:
rebase + 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...