ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Denis Magda <dma...@apache.org>
Subject Re: Stable/experimental releases
Date Mon, 09 Jul 2018 19:18:28 GMT
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 <
dkarachentsev@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 <vozerov@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 <
> >> dkarachentsev@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!
> >>>
> >>>
> >>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message