New release cycle

[filrak]

Motivation and backstory

Currently we are releasing Vue Storefront versions once a month. While this is great in terms of delivering quick fixes and shipping new features to everyone without waiting ages for a new version of software it has some downsides.

As number of contributions grow it becomes harder and harder to test everything and be sure that the application remains stable and performant in such a short release lifecycle. Moreover one-month release cycle with new features introduced in every of them is not very good for a sustainable and future-proof architecture since everything that is added can be user right after the release which implies that any potential DX issues can't be easly fixed without breaking changes. It also leaves almost no space to adjust PRs to feedback after merging them.

We were thinking about the solution for quite some time. While we still want to keep as short release cycle as possible to give new features and improvements to the community as fast as possible we also want to work more on stability and DX of every new feature.

Solution

The solution to this process that we came up with is two-phase release lifecycle. Divided to release A (new features) and B (stability and testing). Each release phase taking one month.

In the A phase of the release lifecycle we will focus on delivering new features and widening current APIs. After A release community users will be able to grab a beta-ish set of features and start adopting them into their stores, testing and giving feedback.

In the B phase of the release lifecycle we will focus on stability and developer experience. It means:

• in-depth testing of features introduced in release A
• bugfixing and performance stability work
• API corrections for features from phase A based on feedback if the DX wasn;'t as good as expected
• writing unit/integration tests for introduced features.
• simplification of introduced features if possible)

So basicaly you can think about phase A of the release cycle as the one with cutting-edge features that are experimental and phase B as the stable one and ready for production. With this approach all of the community members can test and give feedback about features from phase A during the B milestone of the release and together we will work on making sure that these features work as intended.

During phase B pull requests with new features or additions to the API will not be merged. All of them will wait till phase A when they'll be merged and tested and later polished and tested during the B one. In phase B we merge only bugfixes, tests and overall improvements over previously introduced features but without introducing any new fucntionality.

With new format the next releases will look like this:

• 1.09a - new features and PRs (next month)
• 1.09b - stability, unit testing and API improvements of features introduced in 1.09a (in 2 months)

Please give me your feedback about the proposed new release lifecycle. As always - it's the community choice

[pkarw]

I like this idea; it's very ... "Debianish" (https://www.debian.org/releases/)

We should describe how should we branch our repo then?
https://gitversion.readthedocs.io/en/stable/git-branching-strategies/gitflow/

[filrak]

Maybe old way can stay (more or less) not to complicate too much for people already knowing how it works. Just focus on proper tagging?

[pkarw]

@filrak can we also describe in CONTRIBUTING.MD and PULL_REQUEST.MD the new schema of PR acceptance? It should be transparent

[filrak]

Sure. If we will accept on the New format I'll adjust every doc and add info about how we release stuff into the docs

[patzick]

I think it's a great idea to keep our product stable and to provide better experience to our users.
My proposition would be just creating RC versions. So for example for next release we would have

• v1.9.0-RC.1

tag which is closing the features cycle. Then next features are can still be added to develop (for example by community) and we can focus on stabilising RC. Also community can give us a feedback to RCs. And when we ensure that RC version is stable, then we publish v1.9.0 tag.

[lukeromanowicz]

Great move. This will definitely help us to deliver stable software. I'd keep the naming as @patzick proposed, as it is more informative and widely used comparing to introducing a unique naming system. It also allows us to publish a couple RCs before final release.

[filrak]

I[m not tied at all to the naming system - @patzick proposition seems much better and was used by us previously so it's more natural

[Igloczek]

It's not enough to just give 👍, so I need to drop a comment that I like it.

I also vote to use the npm compatible versioning, so the one proposed by @patzick.

Few ideas/questions from my side

1. How to decide when the release is ready?
   I think just the strict date is not enough and can lead to releasing something not 100% ready.
   What currently comes to my mind is some kind of pre-release checklist, ofc not only for storefront, but the whole platform (is that the right description for the whole backend + frontend of VSF?)
   For example what came out working on our first VSF store - current set of demo data is a bit too optimistic to really test all features of the app, for example even very basic stuff like special prices of the configurable products or bundle products prices, in general, were not working correctly and there is no way to test it on demo data.
   What can be also very useful is some automatically deployed staging environments with different configuration options enabled. It's not that easy to test on local all the stuff manually, it can save a ton of time.
2. Synchronizing releases and workflow rules in all parts of the app
   I think currently only this repo gets proper treatment, but API, m2vsf etc. are not that well managed and it should be changed, for sake of stability.

[pkarw]

Only the positive feedback so far - that's great :)

ad2) I totally agree with You, we should have had pretty much the same standards for https://github.com/DivanteLtd/vue-storefront-api and https://github.com/DivanteLtd/mage2vuestorefront

@filrak and @patzick can You guys set up the Github repositories and PR rules for these projects accordingly?