Re: Stable/experimental releases
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 : > > > >> 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! > >>> > >>> > >>> > >
Re: Stable/experimental releases
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 : 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!
Re: Stable/experimental releases
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 : > 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! > > > > > > >
Re: Stable/experimental releases
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 : > 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! > > >
Stable/experimental releases
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!
