Hi Dmitry,
I think maintenance release is fine only if they will include ONLY
fixes. This will allow to release more frequently, so we do not have to
wait when collect some number of fixes to make a next major version.
So each major release could be named as experimental, and maintenance -
stable.
Thanks!
06.07.2018 16:47, Dmitry Pavlov пишет:
Hi Igniters,
here I will extremely appreciate vision from community members invoved into
release. What is simpler, support 2.7-EA- or 2.7.x?
Taking into account Teamcity state, it is quite honest to have experimental
releases to underline that
- a lot of new code introduced
- and probably new feateure will be more stable in later release.
WDYT?
Sincerely,
Dmitriy Pavlov
чт, 5 июл. 2018 г. в 17:53, Vladimir Ozerov <voze...@gridgain.com>:
Hi Dmitriy,
AFAIK we have an idea to introduce maintenance releases for Ignite. E.g.
2.6.0 - features, 2.6.1+ - stabilization.
This seems to be more standard and flexible approach.
чт, 5 июля 2018 г. в 17:39, Dmitry Karachentsev <
dkarachent...@gridgain.com
:
Hi igniters!
Following our discussions about emergency releases I see that here might
be applied new way for doing releases. Like it was for Linux or like it
is for Ubuntu. I mean do interleaving releases: first is experimental
with newest features and second - with bug fixes ONLY.
For example, odd version number is unstable and even is stable: 2.5
introduces a lot of new features, when 2.6 brings more stability to
product.
Pros:
1. User always has a choice what to choose: cutting edge technology or
release that has less problems.
2. It will be much easier to add more effort to make TC green again, as
fixes are not mixed with features.
3. We may spend more time on prepare stable release and do more rigorous
testing.
4. Stable release may keep 100% compatibility to previous release (not
always, of course) to make it easier to migrate and take important bug
fixes without introducing a new ones.
5. Not all users will fall in critical issues, in other words, only some
group of users will try to use unstable release with experimental
features.
Cons:
1. Necessity of keeping two branches simultaneous: master and stable
release. Migrate fixes between branches.
2. Less users could report about found issues, as consequence of item #5
from pros.
3. A bit more complex release procedure???
I think it's common and right way to create a less buggy product.
What do you think?
Thanks!
