You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Henri Yandell <fl...@gmail.com> on 2010/03/27 22:07:36 UTC
[LANG][COLLECTIONS] Beta releases
Possibly a query for IO too if it's 2.0 has large changes.
Given the large API changes in Lang 3.0 and Collections 4.0, a beta
release seems like a very useful thing (kudos to pbenedict for
convincing of me that months ago on IM :) ).
I'm interested in what advice and thoughts people might have on the
subject. Areas I can think of are:
1) versioning, does JIRA identify the version as 3.0-beta1; or just
have a 3.0 and treat the beta as an invisible release? I'm preferring
the latter.
2) Maven - does the beta go to the main Maven repo, or just tell
people to pull from snapshot (and make sure there are current
snapshots in the snapshot repo)? I'm thinking the latter.
3) Announcements - blogging, announce@ type announcements presumably.
4) Length of time spent in beta. I think we should define this up front.
The intent would be to get early adopters using and finding bugs, but
more importantly drive conversation around the API changes and suggest
new ones. I want us to be able to change an API without having to say
"Yeah, that was dumb - sadly we have to wait 'til 5.0".
I think both Lang and Collections are ready to have a beta release
asap - once some level of documentation is created, both proto release
documentation and something to define the beta testing period.
Any thoughts are much appreciated,
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Nexus for mvn management WAS Re: [LANG][COLLECTIONS] Beta
releases
Posted by Christian Grobmeier <gr...@gmail.com>.
> I've just started using Nexus on Jakarta BSF, and it is easy to use,
> as well has having the benefits of:
> + avoiding accidental release
> + providing access to final artifacts for inspection/voting before release.
> + allowing snapshot release for inspection
> + checks that sigs are OK (I forgot to upload my new sig and it
> complained when I tried to close the upload ready for review)
>
> I've been involved here with Compress, so I've suggested that we trial
> Nexus for the upcoming release. If that is accepted and goes well, I
> think we should roll it out for all Commons projects.
Just found this thread, after reading through it, I think lets give it
a try with Compress.
> We may need to request Nexus access for Commons (not sure if it has
> already been done) but I'm happy to progress that.
Can you request?
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Nexus for mvn management WAS Re: [LANG][COLLECTIONS] Beta
releases
Posted by sebb <se...@gmail.com>.
On 21/05/2010, sebb <se...@gmail.com> wrote:
> On 21/05/2010, Niall Pemberton <ni...@gmail.com> wrote:
> > On Fri, May 21, 2010 at 10:54 AM, sebb <se...@gmail.com> wrote:
> > > On 30/03/2010, Matt Benson <gu...@gmail.com> wrote:
> > >>
> > >> On Mar 30, 2010, at 12:50 AM, Ralph Goers wrote:
> > >>
> > >>
> > >> >
> > >> > On Mar 29, 2010, at 8:11 AM, Matt Benson wrote:
> > >> >
> > >> >
> > >> > >
> > >> > > >
> > >> > > > What was the release process for the sandbox component you and Ralph
> > >> released?
> > >> > > >
> > >> > > >
> > >> > >
> > >> > > To be precise, Ralph and I had worked with Nexus on separate components,
> > >> and as those were sandbox components it goes without saying that they've not
> > >> been through the entire release process. We've only published snapshots,
> > >> and as far as that's concerned, it's not _that_ huge a difference. I feel
> > >> that I have had less trouble publishing snapshots to Nexus than I had to
> > >> p.a.o, though it's been so long I honestly can't recall what precisely my
> > >> problems were--I have a dim recollection of the whole process going to hell
> > >> and my having to manually delete stuff from p.a.o to get things working. I
> > >> also mentioned that "this is the way the wind is blowing": it would appear
> > >> that the entire ASF is moving toward using repository.a.o and in this case
> > >> there's not much point in my trying to sell it, particularly as I personally
> > >> am not known to be a big fan of mvn in general. :P However, I will
> > >> continue with my stammering attempt to explain the additional benefits of
> > >> this change, at risk of failure due to my admittedly shallow understanding
> > >> of the whole process. The primary benefit to the release cycle, as I
> > >> understand it, is the support of the staging step. From what I can glean
> > >> from the documentation, it would seem that when Nexus is used as the target
> > >> repository of a release, a temporary "staging repository" is generated for
> > >> your release. You then provide the staging repository's URL as the basis
> > >> for the release vote, and, once the vote is successfully completed, you use
> > >> the Nexus UI to promote the entire staging repo to public availability. In
> > >> particular, the best soup-to-nuts detail is to be had from
> > >> http://maven.apache.org/developers/release/apache-release.html
> > >> which purports to be a start-to-finish guide for releasing _any_ Maven-based
> > >> ASF project. Noting that our own Commons release instructions have never
> > >> _seemed_ fully-baked (and this is meant with no offense to any of the
> > >> contributors to said documentation), what's available from the mvn team
> > >> would presumably be a step forward to making the release process less
> > >> onerous. The referenced URL also mentions things like cutting the release
> > >> tag for you, but I am pretty sure this is functionality that has existed in
> > >> mvn for quite some time; in fact the details of how to support the RC-based
> > >> approach we use @ Commons would be my only question/concern. As a member of
> > >> both the Commons and Maven PMCs, and the other "suspect" in this case, I
> > >> wonder if Ralph would have more useful details for us here; Dennis's input
> > >> would be similarly welcome.
> > >> > >
> > >> > >
> > >> >
> > >> > I assume I am the Ralph you are referring to?
> > >> >
> > >>
> > >> Do you know another Ralph on both the Commons and Maven PMCs? ;P
> > >>
> > >>
> > >> > To be fair, when I was trying to get the Maven 2 build to work for VFS I
> > >> knew Brian Fox was setting up the Nexus repositories for Apache and that
> > >> they were meant to replace the existing infrastructure. As I recall he gave
> > >> me the settings to use to publish to it, but VFS has not had any releases to
> > >> validate it.
> > >> >
> > >>
> > >> I did mention that there had been no releases.
> > >>
> > >>
> > >> > I've been using Nexus at work for a year,
> > >> >
> > >>
> > >> Same here.
> > >>
> > >>
> > >> > I know the central repo is running on Nexus and I know the Apache repo
> > >> Brian set up has been running for a while now. I see no reason not to use
> > >> it. My understanding is that that repository is where Maven central expects
> > >> to find new ASF artifacts.
> > >> >
> > >>
> > >> That sounds like more informative articulation of my "wind direction"
> > >> comment; thanks.
> > >>
> > >>
> > >> >
> > >> > Other than that, I don't know that I have much useful info to provide,
> > >> however I am sure that Brian Fox would be happy to provide more guidance if
> > >> needed.
> > >
> > > I've just started using Nexus on Jakarta BSF, and it is easy to use,
> > > as well has having the benefits of:
> > > + avoiding accidental release
> > > + providing access to final artifacts for inspection/voting before release.
> > > + allowing snapshot release for inspection
> > > + checks that sigs are OK (I forgot to upload my new sig and it
> > > complained when I tried to close the upload ready for review)
> > >
> > > I've been involved here with Compress, so I've suggested that we trial
> > > Nexus for the upcoming release. If that is accepted and goes well, I
> > > think we should roll it out for all Commons projects.
> > >
> > > AFAIK, we don't need to change the commons parent POM for this (but
> > > this will be apparent shortly!).
> > >
> > > We may need to request Nexus access for Commons (not sure if it has
> > > already been done) but I'm happy to progress that.
> >
> >
> > AFAIK you need to create a JIRA issue and paste in the link to a
> > successful vote thread from the project - see:
> >
> > https://issues.apache.org/jira/browse/INFRA-1896
> >
> > Also am I right in thinking that any component that wants to do this
> > would need to move to a groupid of "org.apache.commons"?
>
>
> Good catch.
>
> I don't see any staging entries except under org.apache, so that might
> well be the case.
>
> I will ask.
>
> Compress is already using o.a.commons.
>
> We don't have to use Nexus for every commons component (and AFAIK we
> don't even need to use it for every release once we start using it -
> I'll check that too).
>
Nexus does not have to continue to be used.
> > Niall
> >
> > > WDYT?
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Nexus for mvn management WAS Re: [LANG][COLLECTIONS] Beta
releases
Posted by sebb <se...@gmail.com>.
On 21/05/2010, Niall Pemberton <ni...@gmail.com> wrote:
> On Fri, May 21, 2010 at 10:54 AM, sebb <se...@gmail.com> wrote:
> > On 30/03/2010, Matt Benson <gu...@gmail.com> wrote:
> >>
> >> On Mar 30, 2010, at 12:50 AM, Ralph Goers wrote:
> >>
> >>
> >> >
> >> > On Mar 29, 2010, at 8:11 AM, Matt Benson wrote:
> >> >
> >> >
> >> > >
> >> > > >
> >> > > > What was the release process for the sandbox component you and Ralph
> >> released?
> >> > > >
> >> > > >
> >> > >
> >> > > To be precise, Ralph and I had worked with Nexus on separate components,
> >> and as those were sandbox components it goes without saying that they've not
> >> been through the entire release process. We've only published snapshots,
> >> and as far as that's concerned, it's not _that_ huge a difference. I feel
> >> that I have had less trouble publishing snapshots to Nexus than I had to
> >> p.a.o, though it's been so long I honestly can't recall what precisely my
> >> problems were--I have a dim recollection of the whole process going to hell
> >> and my having to manually delete stuff from p.a.o to get things working. I
> >> also mentioned that "this is the way the wind is blowing": it would appear
> >> that the entire ASF is moving toward using repository.a.o and in this case
> >> there's not much point in my trying to sell it, particularly as I personally
> >> am not known to be a big fan of mvn in general. :P However, I will
> >> continue with my stammering attempt to explain the additional benefits of
> >> this change, at risk of failure due to my admittedly shallow understanding
> >> of the whole process. The primary benefit to the release cycle, as I
> >> understand it, is the support of the staging step. From what I can glean
> >> from the documentation, it would seem that when Nexus is used as the target
> >> repository of a release, a temporary "staging repository" is generated for
> >> your release. You then provide the staging repository's URL as the basis
> >> for the release vote, and, once the vote is successfully completed, you use
> >> the Nexus UI to promote the entire staging repo to public availability. In
> >> particular, the best soup-to-nuts detail is to be had from
> >> http://maven.apache.org/developers/release/apache-release.html
> >> which purports to be a start-to-finish guide for releasing _any_ Maven-based
> >> ASF project. Noting that our own Commons release instructions have never
> >> _seemed_ fully-baked (and this is meant with no offense to any of the
> >> contributors to said documentation), what's available from the mvn team
> >> would presumably be a step forward to making the release process less
> >> onerous. The referenced URL also mentions things like cutting the release
> >> tag for you, but I am pretty sure this is functionality that has existed in
> >> mvn for quite some time; in fact the details of how to support the RC-based
> >> approach we use @ Commons would be my only question/concern. As a member of
> >> both the Commons and Maven PMCs, and the other "suspect" in this case, I
> >> wonder if Ralph would have more useful details for us here; Dennis's input
> >> would be similarly welcome.
> >> > >
> >> > >
> >> >
> >> > I assume I am the Ralph you are referring to?
> >> >
> >>
> >> Do you know another Ralph on both the Commons and Maven PMCs? ;P
> >>
> >>
> >> > To be fair, when I was trying to get the Maven 2 build to work for VFS I
> >> knew Brian Fox was setting up the Nexus repositories for Apache and that
> >> they were meant to replace the existing infrastructure. As I recall he gave
> >> me the settings to use to publish to it, but VFS has not had any releases to
> >> validate it.
> >> >
> >>
> >> I did mention that there had been no releases.
> >>
> >>
> >> > I've been using Nexus at work for a year,
> >> >
> >>
> >> Same here.
> >>
> >>
> >> > I know the central repo is running on Nexus and I know the Apache repo
> >> Brian set up has been running for a while now. I see no reason not to use
> >> it. My understanding is that that repository is where Maven central expects
> >> to find new ASF artifacts.
> >> >
> >>
> >> That sounds like more informative articulation of my "wind direction"
> >> comment; thanks.
> >>
> >>
> >> >
> >> > Other than that, I don't know that I have much useful info to provide,
> >> however I am sure that Brian Fox would be happy to provide more guidance if
> >> needed.
> >
> > I've just started using Nexus on Jakarta BSF, and it is easy to use,
> > as well has having the benefits of:
> > + avoiding accidental release
> > + providing access to final artifacts for inspection/voting before release.
> > + allowing snapshot release for inspection
> > + checks that sigs are OK (I forgot to upload my new sig and it
> > complained when I tried to close the upload ready for review)
> >
> > I've been involved here with Compress, so I've suggested that we trial
> > Nexus for the upcoming release. If that is accepted and goes well, I
> > think we should roll it out for all Commons projects.
> >
> > AFAIK, we don't need to change the commons parent POM for this (but
> > this will be apparent shortly!).
> >
> > We may need to request Nexus access for Commons (not sure if it has
> > already been done) but I'm happy to progress that.
>
>
> AFAIK you need to create a JIRA issue and paste in the link to a
> successful vote thread from the project - see:
>
> https://issues.apache.org/jira/browse/INFRA-1896
>
> Also am I right in thinking that any component that wants to do this
> would need to move to a groupid of "org.apache.commons"?
Good catch.
I don't see any staging entries except under org.apache, so that might
well be the case.
I will ask.
Compress is already using o.a.commons.
We don't have to use Nexus for every commons component (and AFAIK we
don't even need to use it for every release once we start using it -
I'll check that too).
> Niall
>
> > WDYT?
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Nexus for mvn management WAS Re: [LANG][COLLECTIONS] Beta
releases
Posted by Niall Pemberton <ni...@gmail.com>.
On Fri, May 21, 2010 at 10:54 AM, sebb <se...@gmail.com> wrote:
> On 30/03/2010, Matt Benson <gu...@gmail.com> wrote:
>>
>> On Mar 30, 2010, at 12:50 AM, Ralph Goers wrote:
>>
>>
>> >
>> > On Mar 29, 2010, at 8:11 AM, Matt Benson wrote:
>> >
>> >
>> > >
>> > > >
>> > > > What was the release process for the sandbox component you and Ralph
>> released?
>> > > >
>> > > >
>> > >
>> > > To be precise, Ralph and I had worked with Nexus on separate components,
>> and as those were sandbox components it goes without saying that they've not
>> been through the entire release process. We've only published snapshots,
>> and as far as that's concerned, it's not _that_ huge a difference. I feel
>> that I have had less trouble publishing snapshots to Nexus than I had to
>> p.a.o, though it's been so long I honestly can't recall what precisely my
>> problems were--I have a dim recollection of the whole process going to hell
>> and my having to manually delete stuff from p.a.o to get things working. I
>> also mentioned that "this is the way the wind is blowing": it would appear
>> that the entire ASF is moving toward using repository.a.o and in this case
>> there's not much point in my trying to sell it, particularly as I personally
>> am not known to be a big fan of mvn in general. :P However, I will
>> continue with my stammering attempt to explain the additional benefits of
>> this change, at risk of failure due to my admittedly shallow understanding
>> of the whole process. The primary benefit to the release cycle, as I
>> understand it, is the support of the staging step. From what I can glean
>> from the documentation, it would seem that when Nexus is used as the target
>> repository of a release, a temporary "staging repository" is generated for
>> your release. You then provide the staging repository's URL as the basis
>> for the release vote, and, once the vote is successfully completed, you use
>> the Nexus UI to promote the entire staging repo to public availability. In
>> particular, the best soup-to-nuts detail is to be had from
>> http://maven.apache.org/developers/release/apache-release.html
>> which purports to be a start-to-finish guide for releasing _any_ Maven-based
>> ASF project. Noting that our own Commons release instructions have never
>> _seemed_ fully-baked (and this is meant with no offense to any of the
>> contributors to said documentation), what's available from the mvn team
>> would presumably be a step forward to making the release process less
>> onerous. The referenced URL also mentions things like cutting the release
>> tag for you, but I am pretty sure this is functionality that has existed in
>> mvn for quite some time; in fact the details of how to support the RC-based
>> approach we use @ Commons would be my only question/concern. As a member of
>> both the Commons and Maven PMCs, and the other "suspect" in this case, I
>> wonder if Ralph would have more useful details for us here; Dennis's input
>> would be similarly welcome.
>> > >
>> > >
>> >
>> > I assume I am the Ralph you are referring to?
>> >
>>
>> Do you know another Ralph on both the Commons and Maven PMCs? ;P
>>
>>
>> > To be fair, when I was trying to get the Maven 2 build to work for VFS I
>> knew Brian Fox was setting up the Nexus repositories for Apache and that
>> they were meant to replace the existing infrastructure. As I recall he gave
>> me the settings to use to publish to it, but VFS has not had any releases to
>> validate it.
>> >
>>
>> I did mention that there had been no releases.
>>
>>
>> > I've been using Nexus at work for a year,
>> >
>>
>> Same here.
>>
>>
>> > I know the central repo is running on Nexus and I know the Apache repo
>> Brian set up has been running for a while now. I see no reason not to use
>> it. My understanding is that that repository is where Maven central expects
>> to find new ASF artifacts.
>> >
>>
>> That sounds like more informative articulation of my "wind direction"
>> comment; thanks.
>>
>>
>> >
>> > Other than that, I don't know that I have much useful info to provide,
>> however I am sure that Brian Fox would be happy to provide more guidance if
>> needed.
>
> I've just started using Nexus on Jakarta BSF, and it is easy to use,
> as well has having the benefits of:
> + avoiding accidental release
> + providing access to final artifacts for inspection/voting before release.
> + allowing snapshot release for inspection
> + checks that sigs are OK (I forgot to upload my new sig and it
> complained when I tried to close the upload ready for review)
>
> I've been involved here with Compress, so I've suggested that we trial
> Nexus for the upcoming release. If that is accepted and goes well, I
> think we should roll it out for all Commons projects.
>
> AFAIK, we don't need to change the commons parent POM for this (but
> this will be apparent shortly!).
>
> We may need to request Nexus access for Commons (not sure if it has
> already been done) but I'm happy to progress that.
AFAIK you need to create a JIRA issue and paste in the link to a
successful vote thread from the project - see:
https://issues.apache.org/jira/browse/INFRA-1896
Also am I right in thinking that any component that wants to do this
would need to move to a groupid of "org.apache.commons"?
Niall
> WDYT?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Nexus for mvn management WAS Re: [LANG][COLLECTIONS] Beta
releases
Posted by sebb <se...@gmail.com>.
On 30/03/2010, Matt Benson <gu...@gmail.com> wrote:
>
> On Mar 30, 2010, at 12:50 AM, Ralph Goers wrote:
>
>
> >
> > On Mar 29, 2010, at 8:11 AM, Matt Benson wrote:
> >
> >
> > >
> > > >
> > > > What was the release process for the sandbox component you and Ralph
> released?
> > > >
> > > >
> > >
> > > To be precise, Ralph and I had worked with Nexus on separate components,
> and as those were sandbox components it goes without saying that they've not
> been through the entire release process. We've only published snapshots,
> and as far as that's concerned, it's not _that_ huge a difference. I feel
> that I have had less trouble publishing snapshots to Nexus than I had to
> p.a.o, though it's been so long I honestly can't recall what precisely my
> problems were--I have a dim recollection of the whole process going to hell
> and my having to manually delete stuff from p.a.o to get things working. I
> also mentioned that "this is the way the wind is blowing": it would appear
> that the entire ASF is moving toward using repository.a.o and in this case
> there's not much point in my trying to sell it, particularly as I personally
> am not known to be a big fan of mvn in general. :P However, I will
> continue with my stammering attempt to explain the additional benefits of
> this change, at risk of failure due to my admittedly shallow understanding
> of the whole process. The primary benefit to the release cycle, as I
> understand it, is the support of the staging step. From what I can glean
> from the documentation, it would seem that when Nexus is used as the target
> repository of a release, a temporary "staging repository" is generated for
> your release. You then provide the staging repository's URL as the basis
> for the release vote, and, once the vote is successfully completed, you use
> the Nexus UI to promote the entire staging repo to public availability. In
> particular, the best soup-to-nuts detail is to be had from
> http://maven.apache.org/developers/release/apache-release.html
> which purports to be a start-to-finish guide for releasing _any_ Maven-based
> ASF project. Noting that our own Commons release instructions have never
> _seemed_ fully-baked (and this is meant with no offense to any of the
> contributors to said documentation), what's available from the mvn team
> would presumably be a step forward to making the release process less
> onerous. The referenced URL also mentions things like cutting the release
> tag for you, but I am pretty sure this is functionality that has existed in
> mvn for quite some time; in fact the details of how to support the RC-based
> approach we use @ Commons would be my only question/concern. As a member of
> both the Commons and Maven PMCs, and the other "suspect" in this case, I
> wonder if Ralph would have more useful details for us here; Dennis's input
> would be similarly welcome.
> > >
> > >
> >
> > I assume I am the Ralph you are referring to?
> >
>
> Do you know another Ralph on both the Commons and Maven PMCs? ;P
>
>
> > To be fair, when I was trying to get the Maven 2 build to work for VFS I
> knew Brian Fox was setting up the Nexus repositories for Apache and that
> they were meant to replace the existing infrastructure. As I recall he gave
> me the settings to use to publish to it, but VFS has not had any releases to
> validate it.
> >
>
> I did mention that there had been no releases.
>
>
> > I've been using Nexus at work for a year,
> >
>
> Same here.
>
>
> > I know the central repo is running on Nexus and I know the Apache repo
> Brian set up has been running for a while now. I see no reason not to use
> it. My understanding is that that repository is where Maven central expects
> to find new ASF artifacts.
> >
>
> That sounds like more informative articulation of my "wind direction"
> comment; thanks.
>
>
> >
> > Other than that, I don't know that I have much useful info to provide,
> however I am sure that Brian Fox would be happy to provide more guidance if
> needed.
I've just started using Nexus on Jakarta BSF, and it is easy to use,
as well has having the benefits of:
+ avoiding accidental release
+ providing access to final artifacts for inspection/voting before release.
+ allowing snapshot release for inspection
+ checks that sigs are OK (I forgot to upload my new sig and it
complained when I tried to close the upload ready for review)
I've been involved here with Compress, so I've suggested that we trial
Nexus for the upcoming release. If that is accepted and goes well, I
think we should roll it out for all Commons projects.
AFAIK, we don't need to change the commons parent POM for this (but
this will be apparent shortly!).
We may need to request Nexus access for Commons (not sure if it has
already been done) but I'm happy to progress that.
WDYT?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Nexus for mvn management WAS Re: [LANG][COLLECTIONS] Beta releases
Posted by Matt Benson <gu...@gmail.com>.
On Mar 30, 2010, at 12:50 AM, Ralph Goers wrote:
>
> On Mar 29, 2010, at 8:11 AM, Matt Benson wrote:
>
>>>
>>> What was the release process for the sandbox component you and
>>> Ralph released?
>>>
>>
>> To be precise, Ralph and I had worked with Nexus on separate
>> components, and as those were sandbox components it goes without
>> saying that they've not been through the entire release process.
>> We've only published snapshots, and as far as that's concerned,
>> it's not _that_ huge a difference. I feel that I have had less
>> trouble publishing snapshots to Nexus than I had to p.a.o, though
>> it's been so long I honestly can't recall what precisely my
>> problems were--I have a dim recollection of the whole process
>> going to hell and my having to manually delete stuff from p.a.o to
>> get things working. I also mentioned that "this is the way the
>> wind is blowing": it would appear that the entire ASF is moving
>> toward using repository.a.o and in this case there's not much
>> point in my trying to sell it, particularly as I personally am not
>> known to be a big fan of mvn in general. :P However, I will
>> continue with my stammering attempt to explain the additional
>> benefits of this change, at risk of failure due to my admittedly
>> shallow understanding of the whole process. The primary benefit
>> to the release cycle, as I understand it, is the support of the
>> staging step. From what I can glean from the documentation, it
>> would seem that when Nexus is used as the target repository of a
>> release, a temporary "staging repository" is generated for your
>> release. You then provide the staging repository's URL as the
>> basis for the release vote, and, once the vote is successfully
>> completed, you use the Nexus UI to promote the entire staging repo
>> to public availability. In particular, the best soup-to-nuts
>> detail is to be had from http://maven.apache.org/developers/
>> release/apache-release.html which purports to be a start-to-finish
>> guide for releasing _any_ Maven-based ASF project. Noting that
>> our own Commons release instructions have never _seemed_ fully-
>> baked (and this is meant with no offense to any of the
>> contributors to said documentation), what's available from the mvn
>> team would presumably be a step forward to making the release
>> process less onerous. The referenced URL also mentions things
>> like cutting the release tag for you, but I am pretty sure this is
>> functionality that has existed in mvn for quite some time; in fact
>> the details of how to support the RC-based approach we use @
>> Commons would be my only question/concern. As a member of both
>> the Commons and Maven PMCs, and the other "suspect" in this case,
>> I wonder if Ralph would have more useful details for us here;
>> Dennis's input would be similarly welcome.
>>
>
> I assume I am the Ralph you are referring to?
Do you know another Ralph on both the Commons and Maven PMCs? ;P
> To be fair, when I was trying to get the Maven 2 build to work for
> VFS I knew Brian Fox was setting up the Nexus repositories for
> Apache and that they were meant to replace the existing
> infrastructure. As I recall he gave me the settings to use to
> publish to it, but VFS has not had any releases to validate it.
I did mention that there had been no releases.
> I've been using Nexus at work for a year,
Same here.
> I know the central repo is running on Nexus and I know the Apache
> repo Brian set up has been running for a while now. I see no reason
> not to use it. My understanding is that that repository is where
> Maven central expects to find new ASF artifacts.
That sounds like more informative articulation of my "wind direction"
comment; thanks.
>
> Other than that, I don't know that I have much useful info to
> provide, however I am sure that Brian Fox would be happy to provide
> more guidance if needed.
Thanks!
-Matt
>
> Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Nexus for mvn management WAS Re: [LANG][COLLECTIONS] Beta releases
Posted by Ralph Goers <ra...@dslextreme.com>.
On Mar 29, 2010, at 8:11 AM, Matt Benson wrote:
>>
>> What was the release process for the sandbox component you and Ralph released?
>>
>
> To be precise, Ralph and I had worked with Nexus on separate components, and as those were sandbox components it goes without saying that they've not been through the entire release process. We've only published snapshots, and as far as that's concerned, it's not _that_ huge a difference. I feel that I have had less trouble publishing snapshots to Nexus than I had to p.a.o, though it's been so long I honestly can't recall what precisely my problems were--I have a dim recollection of the whole process going to hell and my having to manually delete stuff from p.a.o to get things working. I also mentioned that "this is the way the wind is blowing": it would appear that the entire ASF is moving toward using repository.a.o and in this case there's not much point in my trying to sell it, particularly as I personally am not known to be a big fan of mvn in general. :P However, I will continue with my stammering attempt to explain the additional benefits of this change, at risk of failure due to my admittedly shallow understanding of the whole process. The primary benefit to the release cycle, as I understand it, is the support of the staging step. From what I can glean from the documentation, it would seem that when Nexus is used as the target repository of a release, a temporary "staging repository" is generated for your release. You then provide the staging repository's URL as the basis for the release vote, and, once the vote is successfully completed, you use the Nexus UI to promote the entire staging repo to public availability. In particular, the best soup-to-nuts detail is to be had from http://maven.apache.org/developers/release/apache-release.html which purports to be a start-to-finish guide for releasing _any_ Maven-based ASF project. Noting that our own Commons release instructions have never _seemed_ fully-baked (and this is meant with no offense to any of the contributors to said documentation), what's available from the mvn team would presumably be a step forward to making the release process less onerous. The referenced URL also mentions things like cutting the release tag for you, but I am pretty sure this is functionality that has existed in mvn for quite some time; in fact the details of how to support the RC-based approach we use @ Commons would be my only question/concern. As a member of both the Commons and Maven PMCs, and the other "suspect" in this case, I wonder if Ralph would have more useful details for us here; Dennis's input would be similarly welcome.
>
I assume I am the Ralph you are referring to? To be fair, when I was trying to get the Maven 2 build to work for VFS I knew Brian Fox was setting up the Nexus repositories for Apache and that they were meant to replace the existing infrastructure. As I recall he gave me the settings to use to publish to it, but VFS has not had any releases to validate it. I've been using Nexus at work for a year, I know the central repo is running on Nexus and I know the Apache repo Brian set up has been running for a while now. I see no reason not to use it. My understanding is that that repository is where Maven central expects to find new ASF artifacts.
Other than that, I don't know that I have much useful info to provide, however I am sure that Brian Fox would be happy to provide more guidance if needed.
Ralph
Re: Nexus for mvn management WAS Re: [LANG][COLLECTIONS] Beta releases
Posted by Phil Steitz <ph...@gmail.com>.
Dennis Lundberg wrote:
> On 2010-03-29 17:11, Matt Benson wrote:
>> On Mar 28, 2010, at 1:00 PM, Henri Yandell wrote:
>>
>>> On Sun, Mar 28, 2010 at 10:29 AM, Matt Benson <gu...@gmail.com>
>>> wrote:
>>>> On Mar 28, 2010, at 11:29 AM, Henri Yandell wrote:
>>>>
>>>>> On Sun, Mar 28, 2010 at 6:40 AM, Matt Benson <gu...@gmail.com>
>>>>> wrote:
>>>>>> On Mar 27, 2010, at 4:07 PM, Henri Yandell wrote:
>>>>>>
>>>>>>> Possibly a query for IO too if it's 2.0 has large changes.
>>>>>>>
>>>>>>> Given the large API changes in Lang 3.0 and Collections 4.0, a beta
>>>>>>> release seems like a very useful thing (kudos to pbenedict for
>>>>>>> convincing of me that months ago on IM :) ).
>>>>>>>
>>>>>>> I'm interested in what advice and thoughts people might have on the
>>>>>>> subject. Areas I can think of are:
>>>>>>>
>>>>>>> 1) versioning, does JIRA identify the version as 3.0-beta1; or just
>>>>>>> have a 3.0 and treat the beta as an invisible release? I'm preferring
>>>>>>> the latter.
>>>>>>> 2) Maven - does the beta go to the main Maven repo, or just tell
>>>>>>> people to pull from snapshot (and make sure there are current
>>>>>>> snapshots in the snapshot repo)? I'm thinking the latter.
>>>>>>> 3) Announcements - blogging, announce@ type announcements presumably.
>>>>>>> 4) Length of time spent in beta. I think we should define this up
>>>>>>> front.
>>>>>>>
>>>>>>> The intent would be to get early adopters using and finding bugs, but
>>>>>>> more importantly drive conversation around the API changes and
>>>>>>> suggest
>>>>>>> new ones. I want us to be able to change an API without having to say
>>>>>>> "Yeah, that was dumb - sadly we have to wait 'til 5.0".
>>>>>>>
>>>>>>> I think both Lang and Collections are ready to have a beta release
>>>>>>> asap - once some level of documentation is created, both proto
>>>>>>> release
>>>>>>> documentation and something to define the beta testing period.
>>>>>>>
>>>>>>> Any thoughts are much appreciated,
>>>>>> While we're somewhat on-topic, I would heartily suggest that we
>>>>>> give due
>>>>>> consideration to switching to the Nexus install at repository.a.o
>>>>>> for the
>>>>>> Commons release cycles. This is the way the wind is blowing, seems to
>>>>>> make
>>>>>> management easier, and is mostly if not completely already set up as
>>>>>> Ralph
>>>>>> and I have been deploying sandbox snapshots there for some time. A
>>>>>> formal
>>>>>> PMC vote to do all our releases through Nexus would be best, though we
>>>>>> _could_ continue to do this one component at a time; see
>>>>>> http://issues.apache.org/jira/browse/INFRA-1896.
>>>>> What would using Nexus change about our release process?
>>>>>
>>>> It's pretty well-documented from the JIRA issue I referenced above.
>>>> AIUI we
>>>> would tweak (or, more likely, de-tweak) some things in our parent POM
>>>> hierarchy such that the release cycles of snapshot, RC, and release
>>>> would
>>>> all be managed through mvn goals. On the whole there should be much
>>>> less
>>>> manual intervention required for the whole process.
>>> There's a lot of documentation there and let's assume I'm too lazy to
>>> go read a chapter of a book to understand your proposal :)
>>>
>>> What was the release process for the sandbox component you and Ralph
>>> released?
>>>
>> To be precise, Ralph and I had worked with Nexus on separate components,
>> and as those were sandbox components it goes without saying that they've
>> not been through the entire release process. We've only published
>> snapshots, and as far as that's concerned, it's not _that_ huge a
>> difference. I feel that I have had less trouble publishing snapshots to
>> Nexus than I had to p.a.o, though it's been so long I honestly can't
>> recall what precisely my problems were--I have a dim recollection of the
>> whole process going to hell and my having to manually delete stuff from
>> p.a.o to get things working. I also mentioned that "this is the way the
>> wind is blowing": it would appear that the entire ASF is moving toward
>> using repository.a.o and in this case there's not much point in my
>> trying to sell it, particularly as I personally am not known to be a big
>> fan of mvn in general. :P However, I will continue with my stammering
>> attempt to explain the additional benefits of this change, at risk of
>> failure due to my admittedly shallow understanding of the whole
>> process. The primary benefit to the release cycle, as I understand it,
>> is the support of the staging step. From what I can glean from the
>> documentation, it would seem that when Nexus is used as the target
>> repository of a release, a temporary "staging repository" is generated
>> for your release. You then provide the staging repository's URL as the
>> basis for the release vote, and, once the vote is successfully
>> completed, you use the Nexus UI to promote the entire staging repo to
>> public availability. In particular, the best soup-to-nuts detail is to
>> be had from
>> http://maven.apache.org/developers/release/apache-release.html which
>> purports to be a start-to-finish guide for releasing _any_ Maven-based
>> ASF project. Noting that our own Commons release instructions have
>> never _seemed_ fully-baked (and this is meant with no offense to any of
>> the contributors to said documentation), what's available from the mvn
>> team would presumably be a step forward to making the release process
>> less onerous. The referenced URL also mentions things like cutting the
>> release tag for you, but I am pretty sure this is functionality that has
>> existed in mvn for quite some time; in fact the details of how to
>> support the RC-based approach we use @ Commons would be my only
>> question/concern. As a member of both the Commons and Maven PMCs, and
>> the other "suspect" in this case, I wonder if Ralph would have more
>> useful details for us here; Dennis's input would be similarly welcome.
>
> In my view the most important gain of using Nexus is the fact that a
> release will never be accidental. Any attempt to release a component
> will halt in Nexus, until the RM goes there to promote it. This usually
> happens after a vote has been held. This will effectively prevent any
> rogue SNAPSHOT making its way to the Central repository. We do have some
> safeguards against this in the current Commons parent POM, but they
> require the use of profiles.
>
> We've been using Nexus in the release process for Maven itself for a
> while now. As with any new system there are a couple of tasks that you
> need to learn simply because they are new to you. The documentation (as
> linked to by Matt) is now very good and includes screen shots of the web
> UI that you use to promote a release.
Can you go directly to staging - i.e., can we push a completed RC to
Nexus as we do to our public_html directories and then promote it
from there, or do we have to use the release plugin and pom config
to somehow have nexus involved in cutting the rc?
Phil
>
>> -Matt
>>
>>> Hen
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Nexus for mvn management WAS Re: [LANG][COLLECTIONS] Beta releases
Posted by Dennis Lundberg <de...@apache.org>.
On 2010-03-29 17:11, Matt Benson wrote:
>
> On Mar 28, 2010, at 1:00 PM, Henri Yandell wrote:
>
>> On Sun, Mar 28, 2010 at 10:29 AM, Matt Benson <gu...@gmail.com>
>> wrote:
>>>
>>> On Mar 28, 2010, at 11:29 AM, Henri Yandell wrote:
>>>
>>>> On Sun, Mar 28, 2010 at 6:40 AM, Matt Benson <gu...@gmail.com>
>>>> wrote:
>>>>>
>>>>> On Mar 27, 2010, at 4:07 PM, Henri Yandell wrote:
>>>>>
>>>>>> Possibly a query for IO too if it's 2.0 has large changes.
>>>>>>
>>>>>> Given the large API changes in Lang 3.0 and Collections 4.0, a beta
>>>>>> release seems like a very useful thing (kudos to pbenedict for
>>>>>> convincing of me that months ago on IM :) ).
>>>>>>
>>>>>> I'm interested in what advice and thoughts people might have on the
>>>>>> subject. Areas I can think of are:
>>>>>>
>>>>>> 1) versioning, does JIRA identify the version as 3.0-beta1; or just
>>>>>> have a 3.0 and treat the beta as an invisible release? I'm preferring
>>>>>> the latter.
>>>>>> 2) Maven - does the beta go to the main Maven repo, or just tell
>>>>>> people to pull from snapshot (and make sure there are current
>>>>>> snapshots in the snapshot repo)? I'm thinking the latter.
>>>>>> 3) Announcements - blogging, announce@ type announcements presumably.
>>>>>> 4) Length of time spent in beta. I think we should define this up
>>>>>> front.
>>>>>>
>>>>>> The intent would be to get early adopters using and finding bugs, but
>>>>>> more importantly drive conversation around the API changes and
>>>>>> suggest
>>>>>> new ones. I want us to be able to change an API without having to say
>>>>>> "Yeah, that was dumb - sadly we have to wait 'til 5.0".
>>>>>>
>>>>>> I think both Lang and Collections are ready to have a beta release
>>>>>> asap - once some level of documentation is created, both proto
>>>>>> release
>>>>>> documentation and something to define the beta testing period.
>>>>>>
>>>>>> Any thoughts are much appreciated,
>>>>>
>>>>> While we're somewhat on-topic, I would heartily suggest that we
>>>>> give due
>>>>> consideration to switching to the Nexus install at repository.a.o
>>>>> for the
>>>>> Commons release cycles. This is the way the wind is blowing, seems to
>>>>> make
>>>>> management easier, and is mostly if not completely already set up as
>>>>> Ralph
>>>>> and I have been deploying sandbox snapshots there for some time. A
>>>>> formal
>>>>> PMC vote to do all our releases through Nexus would be best, though we
>>>>> _could_ continue to do this one component at a time; see
>>>>> http://issues.apache.org/jira/browse/INFRA-1896.
>>>>
>>>> What would using Nexus change about our release process?
>>>>
>>>
>>> It's pretty well-documented from the JIRA issue I referenced above.
>>> AIUI we
>>> would tweak (or, more likely, de-tweak) some things in our parent POM
>>> hierarchy such that the release cycles of snapshot, RC, and release
>>> would
>>> all be managed through mvn goals. On the whole there should be much
>>> less
>>> manual intervention required for the whole process.
>>
>> There's a lot of documentation there and let's assume I'm too lazy to
>> go read a chapter of a book to understand your proposal :)
>>
>> What was the release process for the sandbox component you and Ralph
>> released?
>>
>
> To be precise, Ralph and I had worked with Nexus on separate components,
> and as those were sandbox components it goes without saying that they've
> not been through the entire release process. We've only published
> snapshots, and as far as that's concerned, it's not _that_ huge a
> difference. I feel that I have had less trouble publishing snapshots to
> Nexus than I had to p.a.o, though it's been so long I honestly can't
> recall what precisely my problems were--I have a dim recollection of the
> whole process going to hell and my having to manually delete stuff from
> p.a.o to get things working. I also mentioned that "this is the way the
> wind is blowing": it would appear that the entire ASF is moving toward
> using repository.a.o and in this case there's not much point in my
> trying to sell it, particularly as I personally am not known to be a big
> fan of mvn in general. :P However, I will continue with my stammering
> attempt to explain the additional benefits of this change, at risk of
> failure due to my admittedly shallow understanding of the whole
> process. The primary benefit to the release cycle, as I understand it,
> is the support of the staging step. From what I can glean from the
> documentation, it would seem that when Nexus is used as the target
> repository of a release, a temporary "staging repository" is generated
> for your release. You then provide the staging repository's URL as the
> basis for the release vote, and, once the vote is successfully
> completed, you use the Nexus UI to promote the entire staging repo to
> public availability. In particular, the best soup-to-nuts detail is to
> be had from
> http://maven.apache.org/developers/release/apache-release.html which
> purports to be a start-to-finish guide for releasing _any_ Maven-based
> ASF project. Noting that our own Commons release instructions have
> never _seemed_ fully-baked (and this is meant with no offense to any of
> the contributors to said documentation), what's available from the mvn
> team would presumably be a step forward to making the release process
> less onerous. The referenced URL also mentions things like cutting the
> release tag for you, but I am pretty sure this is functionality that has
> existed in mvn for quite some time; in fact the details of how to
> support the RC-based approach we use @ Commons would be my only
> question/concern. As a member of both the Commons and Maven PMCs, and
> the other "suspect" in this case, I wonder if Ralph would have more
> useful details for us here; Dennis's input would be similarly welcome.
In my view the most important gain of using Nexus is the fact that a
release will never be accidental. Any attempt to release a component
will halt in Nexus, until the RM goes there to promote it. This usually
happens after a vote has been held. This will effectively prevent any
rogue SNAPSHOT making its way to the Central repository. We do have some
safeguards against this in the current Commons parent POM, but they
require the use of profiles.
We've been using Nexus in the release process for Maven itself for a
while now. As with any new system there are a couple of tasks that you
need to learn simply because they are new to you. The documentation (as
linked to by Matt) is now very good and includes screen shots of the web
UI that you use to promote a release.
>
> -Matt
>
>> Hen
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Nexus for mvn management WAS Re: [LANG][COLLECTIONS] Beta releases
Posted by Matt Benson <gu...@gmail.com>.
On Mar 28, 2010, at 1:00 PM, Henri Yandell wrote:
> On Sun, Mar 28, 2010 at 10:29 AM, Matt Benson
> <gu...@gmail.com> wrote:
>>
>> On Mar 28, 2010, at 11:29 AM, Henri Yandell wrote:
>>
>>> On Sun, Mar 28, 2010 at 6:40 AM, Matt Benson
>>> <gu...@gmail.com> wrote:
>>>>
>>>> On Mar 27, 2010, at 4:07 PM, Henri Yandell wrote:
>>>>
>>>>> Possibly a query for IO too if it's 2.0 has large changes.
>>>>>
>>>>> Given the large API changes in Lang 3.0 and Collections 4.0, a
>>>>> beta
>>>>> release seems like a very useful thing (kudos to pbenedict for
>>>>> convincing of me that months ago on IM :) ).
>>>>>
>>>>> I'm interested in what advice and thoughts people might have on
>>>>> the
>>>>> subject. Areas I can think of are:
>>>>>
>>>>> 1) versioning, does JIRA identify the version as 3.0-beta1; or
>>>>> just
>>>>> have a 3.0 and treat the beta as an invisible release? I'm
>>>>> preferring
>>>>> the latter.
>>>>> 2) Maven - does the beta go to the main Maven repo, or just tell
>>>>> people to pull from snapshot (and make sure there are current
>>>>> snapshots in the snapshot repo)? I'm thinking the latter.
>>>>> 3) Announcements - blogging, announce@ type announcements
>>>>> presumably.
>>>>> 4) Length of time spent in beta. I think we should define this
>>>>> up front.
>>>>>
>>>>> The intent would be to get early adopters using and finding
>>>>> bugs, but
>>>>> more importantly drive conversation around the API changes and
>>>>> suggest
>>>>> new ones. I want us to be able to change an API without having
>>>>> to say
>>>>> "Yeah, that was dumb - sadly we have to wait 'til 5.0".
>>>>>
>>>>> I think both Lang and Collections are ready to have a beta release
>>>>> asap - once some level of documentation is created, both proto
>>>>> release
>>>>> documentation and something to define the beta testing period.
>>>>>
>>>>> Any thoughts are much appreciated,
>>>>
>>>> While we're somewhat on-topic, I would heartily suggest that we
>>>> give due
>>>> consideration to switching to the Nexus install at
>>>> repository.a.o for the
>>>> Commons release cycles. This is the way the wind is blowing,
>>>> seems to
>>>> make
>>>> management easier, and is mostly if not completely already set
>>>> up as
>>>> Ralph
>>>> and I have been deploying sandbox snapshots there for some time. A
>>>> formal
>>>> PMC vote to do all our releases through Nexus would be best,
>>>> though we
>>>> _could_ continue to do this one component at a time; see
>>>> http://issues.apache.org/jira/browse/INFRA-1896.
>>>
>>> What would using Nexus change about our release process?
>>>
>>
>> It's pretty well-documented from the JIRA issue I referenced
>> above. AIUI we
>> would tweak (or, more likely, de-tweak) some things in our parent POM
>> hierarchy such that the release cycles of snapshot, RC, and
>> release would
>> all be managed through mvn goals. On the whole there should be
>> much less
>> manual intervention required for the whole process.
>
> There's a lot of documentation there and let's assume I'm too lazy to
> go read a chapter of a book to understand your proposal :)
>
> What was the release process for the sandbox component you and
> Ralph released?
>
To be precise, Ralph and I had worked with Nexus on separate
components, and as those were sandbox components it goes without
saying that they've not been through the entire release process.
We've only published snapshots, and as far as that's concerned, it's
not _that_ huge a difference. I feel that I have had less trouble
publishing snapshots to Nexus than I had to p.a.o, though it's been
so long I honestly can't recall what precisely my problems were--I
have a dim recollection of the whole process going to hell and my
having to manually delete stuff from p.a.o to get things working. I
also mentioned that "this is the way the wind is blowing": it would
appear that the entire ASF is moving toward using repository.a.o and
in this case there's not much point in my trying to sell it,
particularly as I personally am not known to be a big fan of mvn in
general. :P However, I will continue with my stammering attempt to
explain the additional benefits of this change, at risk of failure
due to my admittedly shallow understanding of the whole process. The
primary benefit to the release cycle, as I understand it, is the
support of the staging step. From what I can glean from the
documentation, it would seem that when Nexus is used as the target
repository of a release, a temporary "staging repository" is
generated for your release. You then provide the staging
repository's URL as the basis for the release vote, and, once the
vote is successfully completed, you use the Nexus UI to promote the
entire staging repo to public availability. In particular, the best
soup-to-nuts detail is to be had from http://maven.apache.org/
developers/release/apache-release.html which purports to be a start-
to-finish guide for releasing _any_ Maven-based ASF project. Noting
that our own Commons release instructions have never _seemed_ fully-
baked (and this is meant with no offense to any of the contributors
to said documentation), what's available from the mvn team would
presumably be a step forward to making the release process less
onerous. The referenced URL also mentions things like cutting the
release tag for you, but I am pretty sure this is functionality that
has existed in mvn for quite some time; in fact the details of how to
support the RC-based approach we use @ Commons would be my only
question/concern. As a member of both the Commons and Maven PMCs,
and the other "suspect" in this case, I wonder if Ralph would have
more useful details for us here; Dennis's input would be similarly
welcome.
-Matt
> Hen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Nexus for mvn management WAS Re: [LANG][COLLECTIONS] Beta
releases
Posted by Henri Yandell <fl...@gmail.com>.
On Sun, Mar 28, 2010 at 10:29 AM, Matt Benson <gu...@gmail.com> wrote:
>
> On Mar 28, 2010, at 11:29 AM, Henri Yandell wrote:
>
>> On Sun, Mar 28, 2010 at 6:40 AM, Matt Benson <gu...@gmail.com> wrote:
>>>
>>> On Mar 27, 2010, at 4:07 PM, Henri Yandell wrote:
>>>
>>>> Possibly a query for IO too if it's 2.0 has large changes.
>>>>
>>>> Given the large API changes in Lang 3.0 and Collections 4.0, a beta
>>>> release seems like a very useful thing (kudos to pbenedict for
>>>> convincing of me that months ago on IM :) ).
>>>>
>>>> I'm interested in what advice and thoughts people might have on the
>>>> subject. Areas I can think of are:
>>>>
>>>> 1) versioning, does JIRA identify the version as 3.0-beta1; or just
>>>> have a 3.0 and treat the beta as an invisible release? I'm preferring
>>>> the latter.
>>>> 2) Maven - does the beta go to the main Maven repo, or just tell
>>>> people to pull from snapshot (and make sure there are current
>>>> snapshots in the snapshot repo)? I'm thinking the latter.
>>>> 3) Announcements - blogging, announce@ type announcements presumably.
>>>> 4) Length of time spent in beta. I think we should define this up front.
>>>>
>>>> The intent would be to get early adopters using and finding bugs, but
>>>> more importantly drive conversation around the API changes and suggest
>>>> new ones. I want us to be able to change an API without having to say
>>>> "Yeah, that was dumb - sadly we have to wait 'til 5.0".
>>>>
>>>> I think both Lang and Collections are ready to have a beta release
>>>> asap - once some level of documentation is created, both proto release
>>>> documentation and something to define the beta testing period.
>>>>
>>>> Any thoughts are much appreciated,
>>>
>>> While we're somewhat on-topic, I would heartily suggest that we give due
>>> consideration to switching to the Nexus install at repository.a.o for the
>>> Commons release cycles. This is the way the wind is blowing, seems to
>>> make
>>> management easier, and is mostly if not completely already set up as
>>> Ralph
>>> and I have been deploying sandbox snapshots there for some time. A
>>> formal
>>> PMC vote to do all our releases through Nexus would be best, though we
>>> _could_ continue to do this one component at a time; see
>>> http://issues.apache.org/jira/browse/INFRA-1896.
>>
>> What would using Nexus change about our release process?
>>
>
> It's pretty well-documented from the JIRA issue I referenced above. AIUI we
> would tweak (or, more likely, de-tweak) some things in our parent POM
> hierarchy such that the release cycles of snapshot, RC, and release would
> all be managed through mvn goals. On the whole there should be much less
> manual intervention required for the whole process.
There's a lot of documentation there and let's assume I'm too lazy to
go read a chapter of a book to understand your proposal :)
What was the release process for the sandbox component you and Ralph released?
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Nexus for mvn management WAS Re: [LANG][COLLECTIONS] Beta releases
Posted by Matt Benson <gu...@gmail.com>.
On Mar 28, 2010, at 11:29 AM, Henri Yandell wrote:
> On Sun, Mar 28, 2010 at 6:40 AM, Matt Benson <gu...@gmail.com>
> wrote:
>>
>> On Mar 27, 2010, at 4:07 PM, Henri Yandell wrote:
>>
>>> Possibly a query for IO too if it's 2.0 has large changes.
>>>
>>> Given the large API changes in Lang 3.0 and Collections 4.0, a beta
>>> release seems like a very useful thing (kudos to pbenedict for
>>> convincing of me that months ago on IM :) ).
>>>
>>> I'm interested in what advice and thoughts people might have on the
>>> subject. Areas I can think of are:
>>>
>>> 1) versioning, does JIRA identify the version as 3.0-beta1; or just
>>> have a 3.0 and treat the beta as an invisible release? I'm
>>> preferring
>>> the latter.
>>> 2) Maven - does the beta go to the main Maven repo, or just tell
>>> people to pull from snapshot (and make sure there are current
>>> snapshots in the snapshot repo)? I'm thinking the latter.
>>> 3) Announcements - blogging, announce@ type announcements
>>> presumably.
>>> 4) Length of time spent in beta. I think we should define this up
>>> front.
>>>
>>> The intent would be to get early adopters using and finding bugs,
>>> but
>>> more importantly drive conversation around the API changes and
>>> suggest
>>> new ones. I want us to be able to change an API without having to
>>> say
>>> "Yeah, that was dumb - sadly we have to wait 'til 5.0".
>>>
>>> I think both Lang and Collections are ready to have a beta release
>>> asap - once some level of documentation is created, both proto
>>> release
>>> documentation and something to define the beta testing period.
>>>
>>> Any thoughts are much appreciated,
>>
>> While we're somewhat on-topic, I would heartily suggest that we
>> give due
>> consideration to switching to the Nexus install at repository.a.o
>> for the
>> Commons release cycles. This is the way the wind is blowing,
>> seems to make
>> management easier, and is mostly if not completely already set up
>> as Ralph
>> and I have been deploying sandbox snapshots there for some time.
>> A formal
>> PMC vote to do all our releases through Nexus would be best,
>> though we
>> _could_ continue to do this one component at a time; see
>> http://issues.apache.org/jira/browse/INFRA-1896.
>
> What would using Nexus change about our release process?
>
It's pretty well-documented from the JIRA issue I referenced above.
AIUI we would tweak (or, more likely, de-tweak) some things in our
parent POM hierarchy such that the release cycles of snapshot, RC,
and release would all be managed through mvn goals. On the whole
there should be much less manual intervention required for the whole
process.
-Matt
> Hen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Nexus for mvn management WAS Re: [LANG][COLLECTIONS] Beta
releases
Posted by Henri Yandell <fl...@gmail.com>.
On Sun, Mar 28, 2010 at 6:40 AM, Matt Benson <gu...@gmail.com> wrote:
>
> On Mar 27, 2010, at 4:07 PM, Henri Yandell wrote:
>
>> Possibly a query for IO too if it's 2.0 has large changes.
>>
>> Given the large API changes in Lang 3.0 and Collections 4.0, a beta
>> release seems like a very useful thing (kudos to pbenedict for
>> convincing of me that months ago on IM :) ).
>>
>> I'm interested in what advice and thoughts people might have on the
>> subject. Areas I can think of are:
>>
>> 1) versioning, does JIRA identify the version as 3.0-beta1; or just
>> have a 3.0 and treat the beta as an invisible release? I'm preferring
>> the latter.
>> 2) Maven - does the beta go to the main Maven repo, or just tell
>> people to pull from snapshot (and make sure there are current
>> snapshots in the snapshot repo)? I'm thinking the latter.
>> 3) Announcements - blogging, announce@ type announcements presumably.
>> 4) Length of time spent in beta. I think we should define this up front.
>>
>> The intent would be to get early adopters using and finding bugs, but
>> more importantly drive conversation around the API changes and suggest
>> new ones. I want us to be able to change an API without having to say
>> "Yeah, that was dumb - sadly we have to wait 'til 5.0".
>>
>> I think both Lang and Collections are ready to have a beta release
>> asap - once some level of documentation is created, both proto release
>> documentation and something to define the beta testing period.
>>
>> Any thoughts are much appreciated,
>
> While we're somewhat on-topic, I would heartily suggest that we give due
> consideration to switching to the Nexus install at repository.a.o for the
> Commons release cycles. This is the way the wind is blowing, seems to make
> management easier, and is mostly if not completely already set up as Ralph
> and I have been deploying sandbox snapshots there for some time. A formal
> PMC vote to do all our releases through Nexus would be best, though we
> _could_ continue to do this one component at a time; see
> http://issues.apache.org/jira/browse/INFRA-1896.
What would using Nexus change about our release process?
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Nexus for mvn management WAS Re: [LANG][COLLECTIONS] Beta releases
Posted by Matt Benson <gu...@gmail.com>.
On Mar 27, 2010, at 4:07 PM, Henri Yandell wrote:
> Possibly a query for IO too if it's 2.0 has large changes.
>
> Given the large API changes in Lang 3.0 and Collections 4.0, a beta
> release seems like a very useful thing (kudos to pbenedict for
> convincing of me that months ago on IM :) ).
>
> I'm interested in what advice and thoughts people might have on the
> subject. Areas I can think of are:
>
> 1) versioning, does JIRA identify the version as 3.0-beta1; or just
> have a 3.0 and treat the beta as an invisible release? I'm preferring
> the latter.
> 2) Maven - does the beta go to the main Maven repo, or just tell
> people to pull from snapshot (and make sure there are current
> snapshots in the snapshot repo)? I'm thinking the latter.
> 3) Announcements - blogging, announce@ type announcements presumably.
> 4) Length of time spent in beta. I think we should define this up
> front.
>
> The intent would be to get early adopters using and finding bugs, but
> more importantly drive conversation around the API changes and suggest
> new ones. I want us to be able to change an API without having to say
> "Yeah, that was dumb - sadly we have to wait 'til 5.0".
>
> I think both Lang and Collections are ready to have a beta release
> asap - once some level of documentation is created, both proto release
> documentation and something to define the beta testing period.
>
> Any thoughts are much appreciated,
While we're somewhat on-topic, I would heartily suggest that we give
due consideration to switching to the Nexus install at repository.a.o
for the Commons release cycles. This is the way the wind is blowing,
seems to make management easier, and is mostly if not completely
already set up as Ralph and I have been deploying sandbox snapshots
there for some time. A formal PMC vote to do all our releases
through Nexus would be best, though we _could_ continue to do this
one component at a time; see http://issues.apache.org/jira/browse/
INFRA-1896.
-Matt
>
> Hen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
RE: [LANG][COLLECTIONS] Beta releases
Posted by Gary Gregory <GG...@seagullsoftware.com>.
> -----Original Message-----
> From: Henri Yandell [mailto:flamefew@gmail.com]
> Sent: Saturday, March 27, 2010 17:33
> To: Commons Developers List
> Subject: Re: [LANG][COLLECTIONS] Beta releases
>
> On Sat, Mar 27, 2010 at 4:30 PM, sebb <se...@gmail.com> wrote:
> > On 27/03/2010, Gary Gregory <GG...@seagullsoftware.com> wrote:
> >> Hi Hen, well done to get the ball rolling. More below.
> >>
> >>
> >> > -----Original Message-----
> >> > From: Henri Yandell [mailto:flamefew@gmail.com]
> >> > Sent: Saturday, March 27, 2010 14:08
> >> > To: Commons Developers List
> >> > Subject: [LANG][COLLECTIONS] Beta releases
> >> >
> >> > Possibly a query for IO too if it's 2.0 has large changes.
> >> >
> >> > Given the large API changes in Lang 3.0 and Collections 4.0, a
> beta
> >> > release seems like a very useful thing (kudos to pbenedict for
> >> > convincing of me that months ago on IM :) ).
> >> >
> >> > I'm interested in what advice and thoughts people might have on
> the
> >> > subject. Areas I can think of are:
> >> >
> >> > 1) versioning, does JIRA identify the version as 3.0-beta1; or
> just
> >> > have a 3.0 and treat the beta as an invisible release? I'm
> preferring
> >> > the latter.
> >>
> >>
> >> I think there is also "nightly-build" available. If bugs are logged
> against "3.0" and fixed in "3.0", then the understanding is that the
> bug was fixed in the alpha/beta/RC cycle. It seems fine if a little
> mysterious though. +0.
> >>
> >
> > Surely you can just add whatever versions you like to the JIRA
> configuration?
>
> I don't want someone to come along later and have to figure out what
> 3.0 was from the release notes from N 3.0 alpha, beta, gamma releases.
> And I don't want to have to modify lots of issues later to roll into a
> 3.0.
>
> >> > 2) Maven - does the beta go to the main Maven repo, or just tell
> >> > people to pull from snapshot (and make sure there are current
> >> > snapshots in the snapshot repo)? I'm thinking the latter.
> >>
> >>
> >> +1
> >
> > Agreed, should go to snapshot repo. If there are subsequent API
> breaks
> > then having the beta in the main repo is likely to cause grief to
> > others and to us at some point.
> >
> >>
> >>
> >> > 3) Announcements - blogging, announce@ type announcements
> presumably.
> >>
> >>
> >> +1. Same as for a release I would think since we are talking about
> important changes and asking for feedback. A broad audience is
> required.
> >>
> >
> > +1
> >
> >>
> >> > 4) Length of time spent in beta. I think we should define this up
> >> > front.
> >>
> >>
> >> +1. At least 1 month? I would also like to see at least 1 week pre-
> beta warning to allow interested committers to put this on their radar
> and contribute before the beta goes out.
>
> Fair enough. And I'm thinking 3->6 months. Possibly 3 months with a
> 2nd beta then for 3 more months.
That seems like a very long time. Can we deal with something shorter?
>
> >> > The intent would be to get early adopters using and finding bugs,
> but
> >> > more importantly drive conversation around the API changes and
> suggest
> >> > new ones. I want us to be able to change an API without having to
> say
> >> > "Yeah, that was dumb - sadly we have to wait 'til 5.0".
> >>
> >>
> >> That sounds like a good intention, IMO this means at least 2 betas,
> 1) ask for feedback, 2) provide new alpha/beta with feedback changes.
> >>
> >> Tangent: If we are talking about changing APIs, shouldn't these
> really be called Alphas and leave a Beta out for a stable API and bug
> finding only? The drawback is that it might harder to get interest from
> a wide audience on more than one pre-release version.
> >>
> >
> > +1 Alpha to be used for fluid APIs.
> > -1 API changes allowed in Betas.
>
> Betas sound pretty pointless then in this case :) You'd be mad to sign
> up for no API changes in beta for a release with major API changes
> (unless you follow beta-1 with alpha-4).
>
> > So long as the rationale for the naming is well explained - i.e. that
> > Alpha is only used because the API might change, not because of the
> > intrinsic quality of the implementation - I'm hopeful Alpha/Beta
> won't
> > put people off.
>
> *shrug* :)
>
> I don't tend to see public alpha releases anymore, "beta" seems to be
> the phrase for 'this is out, but we're making no promises' even if it
> doesn't make logical sense for there never to be visible alpha
> releases. Call it early-access, or developer-preview :)
>
> Hen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
RE: [LANG][COLLECTIONS] Beta releases
Posted by Gary Gregory <GG...@seagullsoftware.com>.
> -----Original Message-----
> From: Henri Yandell [mailto:flamefew@gmail.com]
> Sent: Saturday, March 27, 2010 17:33
> To: Commons Developers List
> Subject: Re: [LANG][COLLECTIONS] Beta releases
>
> On Sat, Mar 27, 2010 at 4:30 PM, sebb <se...@gmail.com> wrote:
> > On 27/03/2010, Gary Gregory <GG...@seagullsoftware.com> wrote:
> >> Hi Hen, well done to get the ball rolling. More below.
> >>
> >>
> >> > -----Original Message-----
> >> > From: Henri Yandell [mailto:flamefew@gmail.com]
> >> > Sent: Saturday, March 27, 2010 14:08
> >> > To: Commons Developers List
> >> > Subject: [LANG][COLLECTIONS] Beta releases
> >> >
> >> > Possibly a query for IO too if it's 2.0 has large changes.
> >> >
> >> > Given the large API changes in Lang 3.0 and Collections 4.0, a
> beta
> >> > release seems like a very useful thing (kudos to pbenedict for
> >> > convincing of me that months ago on IM :) ).
> >> >
> >> > I'm interested in what advice and thoughts people might have on
> the
> >> > subject. Areas I can think of are:
> >> >
> >> > 1) versioning, does JIRA identify the version as 3.0-beta1; or
> just
> >> > have a 3.0 and treat the beta as an invisible release? I'm
> preferring
> >> > the latter.
> >>
> >>
> >> I think there is also "nightly-build" available. If bugs are logged
> against "3.0" and fixed in "3.0", then the understanding is that the
> bug was fixed in the alpha/beta/RC cycle. It seems fine if a little
> mysterious though. +0.
> >>
> >
> > Surely you can just add whatever versions you like to the JIRA
> configuration?
>
> I don't want someone to come along later and have to figure out what
> 3.0 was from the release notes from N 3.0 alpha, beta, gamma releases.
> And I don't want to have to modify lots of issues later to roll into a
> 3.0.
>
> >> > 2) Maven - does the beta go to the main Maven repo, or just tell
> >> > people to pull from snapshot (and make sure there are current
> >> > snapshots in the snapshot repo)? I'm thinking the latter.
> >>
> >>
> >> +1
> >
> > Agreed, should go to snapshot repo. If there are subsequent API
> breaks
> > then having the beta in the main repo is likely to cause grief to
> > others and to us at some point.
> >
> >>
> >>
> >> > 3) Announcements - blogging, announce@ type announcements
> presumably.
> >>
> >>
> >> +1. Same as for a release I would think since we are talking about
> important changes and asking for feedback. A broad audience is
> required.
> >>
> >
> > +1
> >
> >>
> >> > 4) Length of time spent in beta. I think we should define this up
> >> > front.
> >>
> >>
> >> +1. At least 1 month? I would also like to see at least 1 week pre-
> beta warning to allow interested committers to put this on their radar
> and contribute before the beta goes out.
>
> Fair enough. And I'm thinking 3->6 months. Possibly 3 months with a
> 2nd beta then for 3 more months.
>
> >> > The intent would be to get early adopters using and finding bugs,
> but
> >> > more importantly drive conversation around the API changes and
> suggest
> >> > new ones. I want us to be able to change an API without having to
> say
> >> > "Yeah, that was dumb - sadly we have to wait 'til 5.0".
> >>
> >>
> >> That sounds like a good intention, IMO this means at least 2 betas,
> 1) ask for feedback, 2) provide new alpha/beta with feedback changes.
> >>
> >> Tangent: If we are talking about changing APIs, shouldn't these
> really be called Alphas and leave a Beta out for a stable API and bug
> finding only? The drawback is that it might harder to get interest from
> a wide audience on more than one pre-release version.
> >>
> >
> > +1 Alpha to be used for fluid APIs.
> > -1 API changes allowed in Betas.
>
> Betas sound pretty pointless then in this case :) You'd be mad to sign
> up for no API changes in beta for a release with major API changes
> (unless you follow beta-1 with alpha-4).
>
> > So long as the rationale for the naming is well explained - i.e. that
> > Alpha is only used because the API might change, not because of the
> > intrinsic quality of the implementation - I'm hopeful Alpha/Beta
> won't
> > put people off.
>
> *shrug* :)
>
> I don't tend to see public alpha releases anymore, "beta" seems to be
> the phrase for 'this is out, but we're making no promises' even if it
> doesn't make logical sense for there never to be visible alpha
> releases. Call it early-access, or developer-preview :)
That's true, the formality of milestones from alpha to beta to release seems to have gone out of favor with a variety of alternatives. So we might as well stick to "beta" and have as many of those as we need.
Gary
>
> Hen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [LANG][COLLECTIONS] Beta releases
Posted by Luc Maisonobe <Lu...@free.fr>.
Phil Steitz a écrit :
> Henri Yandell wrote:
>> On Sat, Mar 27, 2010 at 4:30 PM, sebb <se...@gmail.com> wrote:
>>> On 27/03/2010, Gary Gregory <GG...@seagullsoftware.com> wrote:
>>>> Hi Hen, well done to get the ball rolling. More below.
>>>>
>>>>
>>>> > -----Original Message-----
>>>> > From: Henri Yandell [mailto:flamefew@gmail.com]
>>>> > Sent: Saturday, March 27, 2010 14:08
>>>> > To: Commons Developers List
>>>> > Subject: [LANG][COLLECTIONS] Beta releases
>>>> >
>>>> > Possibly a query for IO too if it's 2.0 has large changes.
>>>> >
>>>> > Given the large API changes in Lang 3.0 and Collections 4.0, a beta
>>>> > release seems like a very useful thing (kudos to pbenedict for
>>>> > convincing of me that months ago on IM :) ).
>>>> >
>>>> > I'm interested in what advice and thoughts people might have on the
>>>> > subject. Areas I can think of are:
>>>> >
>>>> > 1) versioning, does JIRA identify the version as 3.0-beta1; or just
>>>> > have a 3.0 and treat the beta as an invisible release? I'm preferring
>>>> > the latter.
>>>>
>>>>
>>>> I think there is also "nightly-build" available. If bugs are logged against "3.0" and fixed in "3.0", then the understanding is that the bug was fixed in the alpha/beta/RC cycle. It seems fine if a little mysterious though. +0.
>>>>
>>> Surely you can just add whatever versions you like to the JIRA configuration?
>> I don't want someone to come along later and have to figure out what
>> 3.0 was from the release notes from N 3.0 alpha, beta, gamma releases.
>> And I don't want to have to modify lots of issues later to roll into a
>> 3.0.
>>
> +1 - best to leave JIRA 3.0
I don't understand the problem.
>
>>>> > 2) Maven - does the beta go to the main Maven repo, or just tell
>>>> > people to pull from snapshot (and make sure there are current
>>>> > snapshots in the snapshot repo)? I'm thinking the latter.
>>>>
> +1 - snapshot
+0
Despite these versions are expected to be less stable and don't want
people to use them for production, they will be officially released, so
they are worth being preserved.
>>>> +1
>
>>> Agreed, should go to snapshot repo. If there are subsequent API breaks
>>> then having the beta in the main repo is likely to cause grief to
>>> others and to us at some point.
>>>
>>>> > 3) Announcements - blogging, announce@ type announcements presumably.
>>>>
>>>>
>>>> +1. Same as for a release I would think since we are talking about important changes and asking for feedback. A broad audience is required.
>>>>
>>> +1
>>>
> +1 - with the right disclaimers in the announcements / messages
+1
>
> We would need to follow the normal release process, including PMC
> vote to release. We should also talk to the infra@ ppl to make sure
> they are OK with the snapshot repo (non-mirrored) hosting. I don't
> think this should be an issue because we are not likely talking
> about a large volume of downloads, but we should at least ask about it.
>
>>>> > 4) Length of time spent in beta. I think we should define this up
>>>> > front.
>>>>
>>>>
>>>> +1. At least 1 month? I would also like to see at least 1 week pre-beta warning to allow interested committers to put this on their radar and contribute before the beta goes out.
>> Fair enough. And I'm thinking 3->6 months. Possibly 3 months with a
>> 2nd beta then for 3 more months.
This seems very long. A long-lived version may be considered stable
enough to users who may think it is a final version despite its name.
Alpha and beta should not live more than a few weeks. One month may be a
good compromise.
>
> Sounds about right.
>>>> > The intent would be to get early adopters using and finding bugs, but
>>>> > more importantly drive conversation around the API changes and suggest
>>>> > new ones. I want us to be able to change an API without having to say
>>>> > "Yeah, that was dumb - sadly we have to wait 'til 5.0".
>>>>
>>>>
>>>> That sounds like a good intention, IMO this means at least 2 betas, 1) ask for feedback, 2) provide new alpha/beta with feedback changes.
>>>>
>>>> Tangent: If we are talking about changing APIs, shouldn't these really be called Alphas and leave a Beta out for a stable API and bug finding only? The drawback is that it might harder to get interest from a wide audience on more than one pre-release version.
>>>>
>>> +1 Alpha to be used for fluid APIs.
>>> -1 API changes allowed in Betas.
>> Betas sound pretty pointless then in this case :) You'd be mad to sign
>> up for no API changes in beta for a release with major API changes
>> (unless you follow beta-1 with alpha-4).
>>
> I think we need to be clear on this from the beginning - the API
> itself is being {alpha, beta}-tested.
>
>>> So long as the rationale for the naming is well explained - i.e. that
>>> Alpha is only used because the API might change, not because of the
>>> intrinsic quality of the implementation - I'm hopeful Alpha/Beta won't
>>> put people off.
>> *shrug* :)
>>
>> I don't tend to see public alpha releases anymore, "beta" seems to be
>> the phrase for 'this is out, but we're making no promises' even if it
>> doesn't make logical sense for there never to be visible alpha
>> releases. Call it early-access, or developer-preview :)
>>
> That could actually be a good reason to call them alphas - sticks
> out as something different from beta. We are asking users not just
> to test the functionality, but actually more importantly to review
> and test the API.
-0 to alpha. This would scare people and we would end up having done a
release for commons developers only, when we want to get some feedback
from outside. Alpha are not released, they correspond to the current
state in the subversion repository, and beta are versions that can go to
the adventurous public.
>
> I think this is a good idea that will help other components once we
> find a way to do it. We probably should have done something similar
> for [math] 2.0 and I can imagine the same kind of situation in the
> future for both [pool] and [dbcp]. Getting major version release
> APIs correct requires somehow cajoling more than just the usual
> suspects into playing with the new APIs and pointing out what is,
> well, "suboptimal" about them.
I agree. We have done some mistakes with [math] 2.0 that could have been
avoided with such a process.
Luc
>
> Thanks, Hen!
>
> Phil
>
>
>> Hen
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [LANG][COLLECTIONS] Beta releases
Posted by Phil Steitz <ph...@gmail.com>.
Henri Yandell wrote:
> On Sat, Mar 27, 2010 at 4:30 PM, sebb <se...@gmail.com> wrote:
>> On 27/03/2010, Gary Gregory <GG...@seagullsoftware.com> wrote:
>>> Hi Hen, well done to get the ball rolling. More below.
>>>
>>>
>>> > -----Original Message-----
>>> > From: Henri Yandell [mailto:flamefew@gmail.com]
>>> > Sent: Saturday, March 27, 2010 14:08
>>> > To: Commons Developers List
>>> > Subject: [LANG][COLLECTIONS] Beta releases
>>> >
>>> > Possibly a query for IO too if it's 2.0 has large changes.
>>> >
>>> > Given the large API changes in Lang 3.0 and Collections 4.0, a beta
>>> > release seems like a very useful thing (kudos to pbenedict for
>>> > convincing of me that months ago on IM :) ).
>>> >
>>> > I'm interested in what advice and thoughts people might have on the
>>> > subject. Areas I can think of are:
>>> >
>>> > 1) versioning, does JIRA identify the version as 3.0-beta1; or just
>>> > have a 3.0 and treat the beta as an invisible release? I'm preferring
>>> > the latter.
>>>
>>>
>>> I think there is also "nightly-build" available. If bugs are logged against "3.0" and fixed in "3.0", then the understanding is that the bug was fixed in the alpha/beta/RC cycle. It seems fine if a little mysterious though. +0.
>>>
>> Surely you can just add whatever versions you like to the JIRA configuration?
>
> I don't want someone to come along later and have to figure out what
> 3.0 was from the release notes from N 3.0 alpha, beta, gamma releases.
> And I don't want to have to modify lots of issues later to roll into a
> 3.0.
>
+1 - best to leave JIRA 3.0
>>> > 2) Maven - does the beta go to the main Maven repo, or just tell
>>> > people to pull from snapshot (and make sure there are current
>>> > snapshots in the snapshot repo)? I'm thinking the latter.
>>>
+1 - snapshot
>>>
>>> +1
>> Agreed, should go to snapshot repo. If there are subsequent API breaks
>> then having the beta in the main repo is likely to cause grief to
>> others and to us at some point.
>>
>>>
>>> > 3) Announcements - blogging, announce@ type announcements presumably.
>>>
>>>
>>> +1. Same as for a release I would think since we are talking about important changes and asking for feedback. A broad audience is required.
>>>
>> +1
>>
+1 - with the right disclaimers in the announcements / messages
We would need to follow the normal release process, including PMC
vote to release. We should also talk to the infra@ ppl to make sure
they are OK with the snapshot repo (non-mirrored) hosting. I don't
think this should be an issue because we are not likely talking
about a large volume of downloads, but we should at least ask about it.
>>> > 4) Length of time spent in beta. I think we should define this up
>>> > front.
>>>
>>>
>>> +1. At least 1 month? I would also like to see at least 1 week pre-beta warning to allow interested committers to put this on their radar and contribute before the beta goes out.
>
> Fair enough. And I'm thinking 3->6 months. Possibly 3 months with a
> 2nd beta then for 3 more months.
Sounds about right.
>
>>> > The intent would be to get early adopters using and finding bugs, but
>>> > more importantly drive conversation around the API changes and suggest
>>> > new ones. I want us to be able to change an API without having to say
>>> > "Yeah, that was dumb - sadly we have to wait 'til 5.0".
>>>
>>>
>>> That sounds like a good intention, IMO this means at least 2 betas, 1) ask for feedback, 2) provide new alpha/beta with feedback changes.
>>>
>>> Tangent: If we are talking about changing APIs, shouldn't these really be called Alphas and leave a Beta out for a stable API and bug finding only? The drawback is that it might harder to get interest from a wide audience on more than one pre-release version.
>>>
>> +1 Alpha to be used for fluid APIs.
>> -1 API changes allowed in Betas.
>
> Betas sound pretty pointless then in this case :) You'd be mad to sign
> up for no API changes in beta for a release with major API changes
> (unless you follow beta-1 with alpha-4).
>
I think we need to be clear on this from the beginning - the API
itself is being {alpha, beta}-tested.
>> So long as the rationale for the naming is well explained - i.e. that
>> Alpha is only used because the API might change, not because of the
>> intrinsic quality of the implementation - I'm hopeful Alpha/Beta won't
>> put people off.
>
> *shrug* :)
>
> I don't tend to see public alpha releases anymore, "beta" seems to be
> the phrase for 'this is out, but we're making no promises' even if it
> doesn't make logical sense for there never to be visible alpha
> releases. Call it early-access, or developer-preview :)
>
That could actually be a good reason to call them alphas - sticks
out as something different from beta. We are asking users not just
to test the functionality, but actually more importantly to review
and test the API.
I think this is a good idea that will help other components once we
find a way to do it. We probably should have done something similar
for [math] 2.0 and I can imagine the same kind of situation in the
future for both [pool] and [dbcp]. Getting major version release
APIs correct requires somehow cajoling more than just the usual
suspects into playing with the new APIs and pointing out what is,
well, "suboptimal" about them.
Thanks, Hen!
Phil
> Hen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [LANG][COLLECTIONS] Beta releases
Posted by Henri Yandell <fl...@gmail.com>.
On Sat, Mar 27, 2010 at 4:30 PM, sebb <se...@gmail.com> wrote:
> On 27/03/2010, Gary Gregory <GG...@seagullsoftware.com> wrote:
>> Hi Hen, well done to get the ball rolling. More below.
>>
>>
>> > -----Original Message-----
>> > From: Henri Yandell [mailto:flamefew@gmail.com]
>> > Sent: Saturday, March 27, 2010 14:08
>> > To: Commons Developers List
>> > Subject: [LANG][COLLECTIONS] Beta releases
>> >
>> > Possibly a query for IO too if it's 2.0 has large changes.
>> >
>> > Given the large API changes in Lang 3.0 and Collections 4.0, a beta
>> > release seems like a very useful thing (kudos to pbenedict for
>> > convincing of me that months ago on IM :) ).
>> >
>> > I'm interested in what advice and thoughts people might have on the
>> > subject. Areas I can think of are:
>> >
>> > 1) versioning, does JIRA identify the version as 3.0-beta1; or just
>> > have a 3.0 and treat the beta as an invisible release? I'm preferring
>> > the latter.
>>
>>
>> I think there is also "nightly-build" available. If bugs are logged against "3.0" and fixed in "3.0", then the understanding is that the bug was fixed in the alpha/beta/RC cycle. It seems fine if a little mysterious though. +0.
>>
>
> Surely you can just add whatever versions you like to the JIRA configuration?
I don't want someone to come along later and have to figure out what
3.0 was from the release notes from N 3.0 alpha, beta, gamma releases.
And I don't want to have to modify lots of issues later to roll into a
3.0.
>> > 2) Maven - does the beta go to the main Maven repo, or just tell
>> > people to pull from snapshot (and make sure there are current
>> > snapshots in the snapshot repo)? I'm thinking the latter.
>>
>>
>> +1
>
> Agreed, should go to snapshot repo. If there are subsequent API breaks
> then having the beta in the main repo is likely to cause grief to
> others and to us at some point.
>
>>
>>
>> > 3) Announcements - blogging, announce@ type announcements presumably.
>>
>>
>> +1. Same as for a release I would think since we are talking about important changes and asking for feedback. A broad audience is required.
>>
>
> +1
>
>>
>> > 4) Length of time spent in beta. I think we should define this up
>> > front.
>>
>>
>> +1. At least 1 month? I would also like to see at least 1 week pre-beta warning to allow interested committers to put this on their radar and contribute before the beta goes out.
Fair enough. And I'm thinking 3->6 months. Possibly 3 months with a
2nd beta then for 3 more months.
>> > The intent would be to get early adopters using and finding bugs, but
>> > more importantly drive conversation around the API changes and suggest
>> > new ones. I want us to be able to change an API without having to say
>> > "Yeah, that was dumb - sadly we have to wait 'til 5.0".
>>
>>
>> That sounds like a good intention, IMO this means at least 2 betas, 1) ask for feedback, 2) provide new alpha/beta with feedback changes.
>>
>> Tangent: If we are talking about changing APIs, shouldn't these really be called Alphas and leave a Beta out for a stable API and bug finding only? The drawback is that it might harder to get interest from a wide audience on more than one pre-release version.
>>
>
> +1 Alpha to be used for fluid APIs.
> -1 API changes allowed in Betas.
Betas sound pretty pointless then in this case :) You'd be mad to sign
up for no API changes in beta for a release with major API changes
(unless you follow beta-1 with alpha-4).
> So long as the rationale for the naming is well explained - i.e. that
> Alpha is only used because the API might change, not because of the
> intrinsic quality of the implementation - I'm hopeful Alpha/Beta won't
> put people off.
*shrug* :)
I don't tend to see public alpha releases anymore, "beta" seems to be
the phrase for 'this is out, but we're making no promises' even if it
doesn't make logical sense for there never to be visible alpha
releases. Call it early-access, or developer-preview :)
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [LANG][COLLECTIONS] Beta releases
Posted by sebb <se...@gmail.com>.
On 27/03/2010, Gary Gregory <GG...@seagullsoftware.com> wrote:
> Hi Hen, well done to get the ball rolling. More below.
>
>
> > -----Original Message-----
> > From: Henri Yandell [mailto:flamefew@gmail.com]
> > Sent: Saturday, March 27, 2010 14:08
> > To: Commons Developers List
> > Subject: [LANG][COLLECTIONS] Beta releases
> >
> > Possibly a query for IO too if it's 2.0 has large changes.
> >
> > Given the large API changes in Lang 3.0 and Collections 4.0, a beta
> > release seems like a very useful thing (kudos to pbenedict for
> > convincing of me that months ago on IM :) ).
> >
> > I'm interested in what advice and thoughts people might have on the
> > subject. Areas I can think of are:
> >
> > 1) versioning, does JIRA identify the version as 3.0-beta1; or just
> > have a 3.0 and treat the beta as an invisible release? I'm preferring
> > the latter.
>
>
> I think there is also "nightly-build" available. If bugs are logged against "3.0" and fixed in "3.0", then the understanding is that the bug was fixed in the alpha/beta/RC cycle. It seems fine if a little mysterious though. +0.
>
Surely you can just add whatever versions you like to the JIRA configuration?
> > 2) Maven - does the beta go to the main Maven repo, or just tell
> > people to pull from snapshot (and make sure there are current
> > snapshots in the snapshot repo)? I'm thinking the latter.
>
>
> +1
Agreed, should go to snapshot repo. If there are subsequent API breaks
then having the beta in the main repo is likely to cause grief to
others and to us at some point.
>
>
> > 3) Announcements - blogging, announce@ type announcements presumably.
>
>
> +1. Same as for a release I would think since we are talking about important changes and asking for feedback. A broad audience is required.
>
+1
>
> > 4) Length of time spent in beta. I think we should define this up
> > front.
>
>
> +1. At least 1 month? I would also like to see at least 1 week pre-beta warning to allow interested committers to put this on their radar and contribute before the beta goes out.
>
>
> >
> > The intent would be to get early adopters using and finding bugs, but
> > more importantly drive conversation around the API changes and suggest
> > new ones. I want us to be able to change an API without having to say
> > "Yeah, that was dumb - sadly we have to wait 'til 5.0".
>
>
> That sounds like a good intention, IMO this means at least 2 betas, 1) ask for feedback, 2) provide new alpha/beta with feedback changes.
>
> Tangent: If we are talking about changing APIs, shouldn't these really be called Alphas and leave a Beta out for a stable API and bug finding only? The drawback is that it might harder to get interest from a wide audience on more than one pre-release version.
>
+1 Alpha to be used for fluid APIs.
-1 API changes allowed in Betas.
So long as the rationale for the naming is well explained - i.e. that
Alpha is only used because the API might change, not because of the
intrinsic quality of the implementation - I'm hopeful Alpha/Beta won't
put people off.
>
> >
> > I think both Lang and Collections are ready to have a beta release
> > asap - once some level of documentation is created, both proto release
> > documentation and something to define the beta testing period.
>
+1 to Alpha.
> See above.
>
>
> Gary
>
>
> >
> > Any thoughts are much appreciated,
> >
> > Hen
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
RE: [LANG][COLLECTIONS] Beta releases
Posted by Gary Gregory <GG...@seagullsoftware.com>.
Hi Hen, well done to get the ball rolling. More below.
> -----Original Message-----
> From: Henri Yandell [mailto:flamefew@gmail.com]
> Sent: Saturday, March 27, 2010 14:08
> To: Commons Developers List
> Subject: [LANG][COLLECTIONS] Beta releases
>
> Possibly a query for IO too if it's 2.0 has large changes.
>
> Given the large API changes in Lang 3.0 and Collections 4.0, a beta
> release seems like a very useful thing (kudos to pbenedict for
> convincing of me that months ago on IM :) ).
>
> I'm interested in what advice and thoughts people might have on the
> subject. Areas I can think of are:
>
> 1) versioning, does JIRA identify the version as 3.0-beta1; or just
> have a 3.0 and treat the beta as an invisible release? I'm preferring
> the latter.
I think there is also "nightly-build" available. If bugs are logged against "3.0" and fixed in "3.0", then the understanding is that the bug was fixed in the alpha/beta/RC cycle. It seems fine if a little mysterious though. +0.
> 2) Maven - does the beta go to the main Maven repo, or just tell
> people to pull from snapshot (and make sure there are current
> snapshots in the snapshot repo)? I'm thinking the latter.
+1
> 3) Announcements - blogging, announce@ type announcements presumably.
+1. Same as for a release I would think since we are talking about important changes and asking for feedback. A broad audience is required.
> 4) Length of time spent in beta. I think we should define this up
> front.
+1. At least 1 month? I would also like to see at least 1 week pre-beta warning to allow interested committers to put this on their radar and contribute before the beta goes out.
>
> The intent would be to get early adopters using and finding bugs, but
> more importantly drive conversation around the API changes and suggest
> new ones. I want us to be able to change an API without having to say
> "Yeah, that was dumb - sadly we have to wait 'til 5.0".
That sounds like a good intention, IMO this means at least 2 betas, 1) ask for feedback, 2) provide new alpha/beta with feedback changes.
Tangent: If we are talking about changing APIs, shouldn't these really be called Alphas and leave a Beta out for a stable API and bug finding only? The drawback is that it might harder to get interest from a wide audience on more than one pre-release version.
>
> I think both Lang and Collections are ready to have a beta release
> asap - once some level of documentation is created, both proto release
> documentation and something to define the beta testing period.
See above.
Gary
>
> Any thoughts are much appreciated,
>
> Hen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [LANG][COLLECTIONS] Beta releases
Posted by Niall Pemberton <ni...@gmail.com>.
On Sat, Mar 27, 2010 at 10:07 PM, Henri Yandell <fl...@gmail.com> wrote:
> Possibly a query for IO too if it's 2.0 has large changes.
>
> Given the large API changes in Lang 3.0 and Collections 4.0, a beta
> release seems like a very useful thing (kudos to pbenedict for
> convincing of me that months ago on IM :) ).
>
> I'm interested in what advice and thoughts people might have on the
> subject. Areas I can think of are:
>
> 1) versioning, does JIRA identify the version as 3.0-beta1; or just
> have a 3.0 and treat the beta as an invisible release? I'm preferring
> the latter.
IMO the former is better.
> 2) Maven - does the beta go to the main Maven repo, or just tell
> people to pull from snapshot (and make sure there are current
> snapshots in the snapshot repo)? I'm thinking the latter.
I think it should be in the main repo - its a proper release and it
will make it easier/more likely for people to test.
> 3) Announcements - blogging, announce@ type announcements presumably.
> 4) Length of time spent in beta. I think we should define this up front.
OK but I don't think it should be too rigid - it should depend on the
level of feedback we get. Why not say minimum of a month and review it
after that.
> The intent would be to get early adopters using and finding bugs, but
> more importantly drive conversation around the API changes and suggest
> new ones. I want us to be able to change an API without having to say
> "Yeah, that was dumb - sadly we have to wait 'til 5.0".
I agree - and thats what happened with the BeanUtils 1.8.0 - we did
change the API between the beta and the final release.
Niall
> I think both Lang and Collections are ready to have a beta release
> asap - once some level of documentation is created, both proto release
> documentation and something to define the beta testing period.
>
> Any thoughts are much appreciated,
>
> Hen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [LANG][COLLECTIONS] Beta releases
Posted by Matt Benson <gu...@gmail.com>.
On Mar 27, 2010, at 4:07 PM, Henri Yandell wrote:
> Possibly a query for IO too if it's 2.0 has large changes.
>
> Given the large API changes in Lang 3.0 and Collections 4.0, a beta
> release seems like a very useful thing (kudos to pbenedict for
> convincing of me that months ago on IM :) ).
>
> I'm interested in what advice and thoughts people might have on the
> subject. Areas I can think of are:
>
> 1) versioning, does JIRA identify the version as 3.0-beta1; or just
> have a 3.0 and treat the beta as an invisible release? I'm preferring
> the latter.
> 2) Maven - does the beta go to the main Maven repo, or just tell
> people to pull from snapshot (and make sure there are current
> snapshots in the snapshot repo)? I'm thinking the latter.
> 3) Announcements - blogging, announce@ type announcements presumably.
> 4) Length of time spent in beta. I think we should define this up
> front.
>
> The intent would be to get early adopters using and finding bugs, but
> more importantly drive conversation around the API changes and suggest
> new ones. I want us to be able to change an API without having to say
> "Yeah, that was dumb - sadly we have to wait 'til 5.0".
>
> I think both Lang and Collections are ready to have a beta release
> asap - once some level of documentation is created, both proto release
> documentation and something to define the beta testing period.
>
> Any thoughts are much appreciated,
Bypassing though not ignoring the interwoven commentary that has
taken place on the thread: does Maven make allowances for alpha/beta/
rc releases in its recognized version numbering system? If an early
adopter depends on o.a.c.lang 3.0 will he get the beta and then the
release when it comes out, as long as he has the snapshot repo
configured? Or are we really talking about pushing 3.0-SNAPSHOT and
simply declaring that 3.0 is currently in "first beta," "second
beta," etc. mode and is available from the snapshot repo?
Echoed thanks for getting the ball rolling here Hen (particularly
since as of my last recollection you were advocating retiring
[COLLECTIONS] including my 4.0 work ;) ),
Matt
>
> Hen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org