You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Leo Sutic <le...@inspireinfrastructure.com> on 2003/08/21 14:19:36 UTC
Release Process for Sandbox Projects
I have moved Avalon Attributes into the Commons Sandbox now, and
would like to get a release out the door. Just so I understand how
this is done: If I understand what I've heard/read correctly,
Sandbox projects aren't released. They have to be accepted into
Commons proper first.
Question: How is this done, what's the process?
Second, I'd like to do the following pretty much immediately:
1. Get the project website up.
I'm quite new to Maven, and as far as I understand, typing:
maven site:deploy
will do this for me. I'm just a bit too afraid to try this
out without getting some confirmation of this first, though...
I have already done everything to properly generate the site
locally - if I look into target/docs then I have a site that
is exactly as I want it.
2. Get an alpha release out. I have some people over at Avalon
who would like a "first cut of code" to look at. Can this be
done inofficially, without acceptance into Commons proper?
/LS
Re: Release Process for Sandbox Projects
Posted by Henri Yandell <ba...@generationjava.com>.
On Sun, 24 Aug 2003, robert burrell donkin wrote:
> the usual rule is that sandbox components cannot be released. this has
> worked very well in the past and i'd be very reluctant to see exceptions
> without compelling reasons.
+1. 'Release' to me means that it is a supported release.
However, code has been released to the public in an unsupported state for
ages. Maven's repo has versions of projects which were not released by the
project [dev, snapshot etc]. Struts regularly tag the Lang CVS with tags
which Lang do not officially support as we did not release them. The
nightly build is another unsupported release.
Personally I think Leo should just use one of these grey-release scenarios
to output an unsupported release.
Will a 1.0-beta really be any different than a telling people to use the
nightly build to start with? I guess the difference is that a 1.0-beta is
stable while the nightly will change. This isn't bad though, as having
people using nightly is where Apache gets its implementation of release
early, release often.
> putting commons-attributes in a state where it *can* be released is an
> important stage in gaining promotion. momentum is also an important factor.
> commons components are small and so communities don't need to be as large
> as for more ambitious products.
+1. Will do far more for the project than some kind of semi-official beta
release.
> there are a couple of simple things that have worked for components in the
> past. the first is sorting out the documentation and the web site. the
> attributes web sites hasn't been updated for almost a year and doesn't
> contain a lot of information. the second is putting something into the
> apache newsletter.
Good ideas.
Hen
Re: Release Process for Sandbox Projects
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
the usual rule is that sandbox components cannot be released. this has
worked very well in the past and i'd be very reluctant to see exceptions
without compelling reasons.
commons-attributes has a nightly build which are often used as SNAPSHOTs.
putting commons-attributes in a state where it *can* be released is an
important stage in gaining promotion. momentum is also an important factor.
commons components are small and so communities don't need to be as large
as for more ambitious products.
there are a couple of simple things that have worked for components in the
past. the first is sorting out the documentation and the web site. the
attributes web sites hasn't been updated for almost a year and doesn't
contain a lot of information. the second is putting something into the
apache newsletter.
- robert
On Sunday, August 24, 2003, at 03:21 PM, Leo Sutic wrote:
>> From: Robert Leland [mailto:rleland@apache.org]
>>
>> It avoids the stigma that comes with the label Alpha.
>
> That is an option, but I personally prefer the alpha -> beta ->
> release candidate -> big one naming scheme. Since commons
> attributes had reached 0.8 or so before I got involved I'm
> going to call my version 2.0. Otherwise you have the stigma of
> version numbers not only seemingly never reaching that .0 release,
> but actually *going backwards*!
>
> I can't really call it 1.4 since that implies some compile-time
> compatibility with all 1.x versions, of which there are none.
>
>> Also I believe it
>> also avoids the version inflation that happens, version 1.0 -
>> 3.0 in 6 months or less.
>
> If I understand the naming correctly then you have this:
>
> Major.Minor.patch:
>
> Major number: If this changes, you have in essence a completely new
> package - no compatibility is guaranteed at all.
>
> Minor number: Recompilation may be needed. (Source compatibility with
> versions with same major number.)
>
> Patch: Binary & source compatible with same major.minor version.
>
> So version inflation would only happen if I during six months push
> out 3 completely incompatible versions, in which case I think I'd:
>
> a) be able to finally shake off any community that could have
> attached itself to my project
>
> b) start finding it hard to get the +1 votes required for release
>
> c) really start thinking about what I'm doing.
>
> /LS
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
RE: Release Process for Sandbox Projects
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Robert Leland [mailto:rleland@apache.org]
>
> It avoids the stigma that comes with the label Alpha.
That is an option, but I personally prefer the alpha -> beta ->
release candidate -> big one naming scheme. Since commons
attributes had reached 0.8 or so before I got involved I'm
going to call my version 2.0. Otherwise you have the stigma of
version numbers not only seemingly never reaching that .0 release,
but actually *going backwards*!
I can't really call it 1.4 since that implies some compile-time
compatibility with all 1.x versions, of which there are none.
> Also I believe it
> also avoids the version inflation that happens, version 1.0 -
> 3.0 in 6 months or less.
If I understand the naming correctly then you have this:
Major.Minor.patch:
Major number: If this changes, you have in essence a completely new
package - no compatibility is guaranteed at all.
Minor number: Recompilation may be needed. (Source compatibility with
versions with same major number.)
Patch: Binary & source compatible with same major.minor version.
So version inflation would only happen if I during six months push
out 3 completely incompatible versions, in which case I think I'd:
a) be able to finally shake off any community that could have
attached itself to my project
b) start finding it hard to get the +1 votes required for release
c) really start thinking about what I'm doing.
/LS
Re: Release Process for Sandbox Projects
Posted by Robert Leland <rl...@apache.org>.
Leo Sutic wrote:
>
>
>>From: Stephen Colebourne [mailto:scolebourne@btopenworld.com]
>>
>>As a warning, my concerns would be the speed of passage
>>through the sandbox. You need to think if you have a
>>community to maintain this in commons proper, and whether
>>people have had enough time to review it.
>>
>>
>
>My understanding was that I needed to go to commons proper
>before even sending out an alpha release. This put me in
>
>
If you use the Major.Minor.Maintenance numbering scheme you can avoid
-initially- calling your software alpha/beta etc ...
It would be 0.4.0 developer release, limited release, general release,
ie Alpha, Beta, Gamma/Production quality. It avoids the stigma that comes
with the label Alpha. Also I believe it also avoids the
version inflation that happens, version 1.0 - 3.0 in 6 months or less.
-Rob
RE: Release Process for Sandbox Projects
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Stephen Colebourne [mailto:scolebourne@btopenworld.com]
>
> As a warning, my concerns would be the speed of passage
> through the sandbox. You need to think if you have a
> community to maintain this in commons proper, and whether
> people have had enough time to review it.
My understanding was that I needed to go to commons proper
before even sending out an alpha release. This put me in
a bit of a catch-22: I need some kind of release in order
to hope to build a community, but I need a community
before I can do a release.
Since Henri set me straight on that one - only the non-alpha,
this-is-the-big-one release requires that the project is
"viable" in terms of community support and so on.
So I figure this: Unless I have a community, there's no point
in making a non-alpha, non-beta release. So I'll go for
an alpha release and see if I get some kind of community
around it. If I do, then the move to commons proper shouldn't
be a problem. If not, then it's a codebase with no users and
should be killed off to make space.
/LS
Re: Release Process for Sandbox Projects
Posted by Stephen Colebourne <sc...@btopenworld.com>.
As a warning, my concerns would be the speed of passage through the sandbox.
You need to think if you have a community to maintain this in commons
proper, and whether people have had enough time to review it.
Now, that may have happened in Avalon-land, or it may not. Just a warning to
try and avoid -1s.
Stephen
----- Original Message -----
From: "Leo Sutic" <le...@inspireinfrastructure.com>
To: "'Jakarta Commons Developers List'" <co...@jakarta.apache.org>
Sent: Thursday, August 21, 2003 4:26 PM
Subject: RE: Release Process for Sandbox Projects
> OK, then I should be set to go...
>
> Thanks!
>
> /LS
>
> > From: Henri Yandell [mailto:bayard@generationjava.com]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
RE: Release Process for Sandbox Projects
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
OK, then I should be set to go...
Thanks!
/LS
> From: Henri Yandell [mailto:bayard@generationjava.com]
RE: Release Process for Sandbox Projects
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
OK, then I should be set to go...
Thanks!
/LS
> From: Henri Yandell [mailto:bayard@generationjava.com]
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Release Process for Sandbox Projects
Posted by Henri Yandell <ba...@generationjava.com>.
On Thu, 21 Aug 2003, Leo Sutic wrote:
> I have moved Avalon Attributes into the Commons Sandbox now, and
> would like to get a release out the door. Just so I understand how
> this is done: If I understand what I've heard/read correctly,
> Sandbox projects aren't released. They have to be accepted into
> Commons proper first.
>
> Question: How is this done, what's the process?
>
> Second, I'd like to do the following pretty much immediately:
>
> 1. Get the project website up.
> I'm quite new to Maven, and as far as I understand, typing:
>
> maven site:deploy
>
> will do this for me. I'm just a bit too afraid to try this
> out without getting some confirmation of this first, though...
>
> I have already done everything to properly generate the site
> locally - if I look into target/docs then I have a site that
> is exactly as I want it.
You can do this on Sandbox without a release.
> 2. Get an alpha release out. I have some people over at Avalon
> who would like a "first cut of code" to look at. Can this be
> done inofficially, without acceptance into Commons proper?
Easiest way might be to push a snapshot up to the maven repository? :)
Or you could just put it at http://www.apache.org/~<your-id>
I can't find the docs on what to do to get into Commons proper. It's
mainly:
Have a PROPOSAL.html and call a vote on the Commons-Dev list.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Release Process for Sandbox Projects
Posted by Henri Yandell <ba...@generationjava.com>.
On Thu, 21 Aug 2003, Leo Sutic wrote:
> I have moved Avalon Attributes into the Commons Sandbox now, and
> would like to get a release out the door. Just so I understand how
> this is done: If I understand what I've heard/read correctly,
> Sandbox projects aren't released. They have to be accepted into
> Commons proper first.
>
> Question: How is this done, what's the process?
>
> Second, I'd like to do the following pretty much immediately:
>
> 1. Get the project website up.
> I'm quite new to Maven, and as far as I understand, typing:
>
> maven site:deploy
>
> will do this for me. I'm just a bit too afraid to try this
> out without getting some confirmation of this first, though...
>
> I have already done everything to properly generate the site
> locally - if I look into target/docs then I have a site that
> is exactly as I want it.
You can do this on Sandbox without a release.
> 2. Get an alpha release out. I have some people over at Avalon
> who would like a "first cut of code" to look at. Can this be
> done inofficially, without acceptance into Commons proper?
Easiest way might be to push a snapshot up to the maven repository? :)
Or you could just put it at http://www.apache.org/~<your-id>
I can't find the docs on what to do to get into Commons proper. It's
mainly:
Have a PROPOSAL.html and call a vote on the Commons-Dev list.
Hen