Hi folks, My vote goes to the three-digits releases numbering - X.Y.Z. If we decide to introduce betas or early access binaries then the version can be extended to X.Y.Z-beta or X.Y.Z-ea.
-- Denis On Fri, Jul 6, 2018 at 7:06 AM Dmitry Karachentsev < dkarachent...@gridgain.com> wrote: > 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! > >>> > >>> > >>> > >
