You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ignite.apache.org by Konstantin Boudnik <co...@apache.org> on 2015/03/03 04:58:12 UTC

Status of 1.0 release

Guys,

it's been a week+ since we have found and I believe fixed the RAT issues.
What are the plans for RC2? Is there anything left that blocks it or it will
be re-spun soon?

-- 
Take care,
  Cos


Re: Status of 1.0 release

Posted by Konstantin Boudnik <co...@apache.org>.
Well, in practice you need to start somewhere. And there always going to be
'so close to the next release'. It's up to the community, but if the release
process is polished enough and well documented, you can literally have them
every a couple of weeks, if needed.

You don't do releases for the mentors, guys ;) Mentors are here to help you to
get comfortable with how releases are done in the Apache, what's required to
have a release, etc. And yes - to catch issues of all sorts if they happen.
So, perhaps spinning RC2 won't such an awful idea: you need to reply to the
feedback you have received during the RC1 trial. And by the time the feedback
from RC2 is implemented, it might be the end of sprint-2 cycle ;)

A mile walk starts you know where ;)
  Cos

On Mon, Mar 02, 2015 at 08:37PM, 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?
> 
> D.
> 
> On Mon, Mar 2, 2015 at 7:58 PM, Konstantin Boudnik <co...@apache.org> wrote:
> 
> > Guys,
> >
> > it's been a week+ since we have found and I believe fixed the RAT issues.
> > What are the plans for RC2? Is there anything left that blocks it or it
> > will
> > be re-spun soon?
> >
> > --
> > Take care,
> >   Cos
> >
> >

Re: Status of 1.0 release

Posted by Konstantin Boudnik <co...@apache.org>.
On Tue, Mar 03, 2015 at 12:09PM, Dmitriy Setrakyan wrote:
> 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
> ideal.
> 
> 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
> double-check.
> 
> From what I hear, it is best to just release the RC2 today in its current
> shape and form.
> 
Yup, I think this is what we are saying.

Cos

> On Mon, Mar 2, 2015 at 10:00 PM, Branko Čibej <br...@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
> >
> >

Re: Status of 1.0 release

Posted by Dmitriy Setrakyan <ds...@apache.org>.
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
ideal.

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
double-check.

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

D.


On Mon, Mar 2, 2015 at 10:00 PM, Branko Čibej <br...@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
>
>

Re: Status of 1.0 release

Posted by Konstantin Boudnik <co...@apache.org>.
On Tue, Mar 03, 2015 at 07:00AM, Branko Čibej 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).

Doesn't seem to apply in Hadoop land (oops, wrong mailing list).


Re: Status of 1.0 release

Posted by Branko Čibej <br...@apache.org>.
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


Re: Status of 1.0 release

Posted by Dmitriy Setrakyan <ds...@apache.org>.
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?

D.

On Mon, Mar 2, 2015 at 7:58 PM, Konstantin Boudnik <co...@apache.org> wrote:

> Guys,
>
> it's been a week+ since we have found and I believe fixed the RAT issues.
> What are the plans for RC2? Is there anything left that blocks it or it
> will
> be re-spun soon?
>
> --
> Take care,
>   Cos
>
>