ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitriy Setrakyan <dsetrak...@apache.org>
Subject Re: Status of 1.0 release
Date Tue, 03 Mar 2015 20:09:54 GMT
I do understand, of course, that the releases are made to the public and
not the mentors :) Perhaps you are reacting to the wording, which was not

What I wanted to do is have a dry-run, to make sure that when we do release
RC2 all other possible issues that generally get flagged are solved. At
this point we believe we fixed all the issues, but it would not hurt to

>From what I hear, it is best to just release the RC2 today in its current
shape and form.


On Mon, Mar 2, 2015 at 10:00 PM, Branko ─îibej <brane@apache.org> wrote:

> On 03.03.2015 05:37, Dmitriy Setrakyan wrote:
> > To my knowledge, RAT issues have been fixed. But given how close we are
> to
> > the end of sprint-2, I want to take this opportunity and finish up some
> > minor remaining JCache compliance issues that leaked through (given that
> we
> > are being pressured by some JCP members to do it).
> >
> > Overall, I think we are about 1.5 weeks away.
> >
> > Do you think it makes sense to have one trial release in the mean time,
> > just to our mentors, to make sure that there are no other outstanding
> > issues?
> No, you make releases to the public, not the mentors. :)
> There are two points to take into account:
>   * Testing and tuning the release process; ideally, it should be as
>     automated as possible, and error-proof. You can only get there if
>     you actually make releases.
>   * API compatibility: I asked some time ago what your compatibility
>     guarantees are, if any (but I sure hope you do have some, even
>     though I don't see them written down anywhere).
> IMO, it's OK to make any kind of release at any time, even if some API
> isn't final, as long as you tell users in advance what they can expect.
> If you make a public beta and explain that APIs such-and-such aren't
> complete yet, that's fine. Certainly better than delaying a release just
> to polish things up ... that'll never happen.
> If you're unsure what to do about API compatibility guidelines, I
> suggest reading:
>     http://apr.apache.org/versioning.html
> APR and Subversion have used these rules successfully for almost 15
> years. It's written with C in mind, but should apply just fine to Java
> (and, in fact, does apply in practice to Subversion's Java bindings).
> -- Brane

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