On 11/17/06, Leo Simons <[EMAIL PROTECTED]> wrote:
On Nov 17, 2006, at 9:36 AM, Cliff Schmidt wrote:
> The Qpid community has been debating whether or not they should
> include an unreleased snapshot version of MINA within their upcoming
> Qpid release, and whether they would even be allowed to do so by
> "Apache rules".
(...)
> Interested in hearing everyone's thoughts (especially PMC members).
Ah, interesting and complex subject...
= IMHO =
(0) above and beyond all the below, release management is not
easily encapsulated in rules like this and (P)PMCs SHOULD
spend serious effort in figuring this kind of thing out for
themselves and their specific situation
+1
(1) for any release from an incubating project...
(2) all dependencies SHOULD have a stable/final release
(3) failing that, all dependencies SHOULD have a
project-sanctioned beta/alpha/snapshot release
(4) failing that, custom builds of all dependencies
SHOULD be clearly identified as such and traceable
to their exact origin, eg
qpid-1.1.4-incubating.zip
lib/
mina-r2475690.qpid-1.1.4-incubating.jar
+1. Revision and who it's for are essential.
(5) the community whose code you're packaging SHOULD
be notified of this activity and MUST NOT have
any serious objections
(6) custom builds of other incubating projects SHOULD
NOT be included at all
One thing I think we shouldn't do is have an incubating project be
deemed less 'safe' that a project outside the ASF. So +1 to SHOULD NOT
rather than MUST NOT. Definitely a place where (0) is expected to take
strong precedence.
(7) the source, license, and status for all dependencies MUST
be clearly documented
(8) for any release from a non-incubating project...
(9) all dependencies SHOULD have a stable/final release
(10) failing that, all dependencies SHOULD have a
project-sanctioned beta/alpha/snapshot release
(11) failing that, custom builds of all dependencies
SHOULD be clearly identified as such and traceable
to their exact origin, eg
qpid-1.1.4-incubating.zip
lib/
mina-r2475690.qpid-1.1.4-incubating.jar
(12) the community whose code you're packaging SHOULD
be notified of this activity and MUST NOT have
any serious objections
(13) custom builds of other incubating projects MUST
NOT be included at all
(14) dependencies SHOULD NOT be incubating projects
(15) the source, license, and status for all dependencies MUST
be clearly documented
= Some ranting to explain and qualify this further =
(0) really is the only clear and unambiguous "rule" if you ask me.
The difference between (1)-(7) and (8)-(15) is between (6) and
(13,14): projects that are not incubating really MUST NOT ship with
custom builds of incubating projects, and I think having dependencies
on incubating projects should also not happen in general (though
there can be good exceptions to this, in particular when the
incubating project was already an established open source project
with a compatible license, eg a dependency on an incubator release of
activemq or wicket would be just fine).
+1
For java projects that following the maven-style naming mechanism,
one example is having a jar which has "SNAPSHOT" in its name, by
itself that DOES NOT satisfy (7) or (15), and "downloaded from
ibiblio" in terms of "where we got it" is also NOT OK.
Yep, banning SNAPSHOTs in releases is becoming the defacto. Afaik, the
Maven2 release plugin does not allow releases with snapshots in the
dependency tree, and we definitely ban such a thing in Commons
releases (we averaged 2 releases a month when we weren't very active -
now we'd probably want to do 1 a week if we could get up to speed; so
Commons has a lot of release discussions).
Snapshot dependencies come back to bite you in many user error
reports. It's not worth the benefit of not having to solve this stuff
up front.
(snip...)
= Applying this opinion of mine to qpid/MINA =
- good to see the discussion
- good to see the question asked
== next steps ==
- try and work within the MINA community to get the release
you need
And have patience here. It may slow your project down, but the ties
between your project and the dependency are worth the slow down.
Geronimo needed Axis to do a 1.4 release; and in the end one of the
Geronimo guys dug in and did a lot of the work for it. Axis needed
Commons to do a release, and an Axis guy dug in and did the work.
Although this can be a pain, the ties between the communities are much
more valuable in the long term than the short-term delay (imnsho etc).
- if that doesn't work out, let the MINA community know you
will build a custom release
I'd like to see reports of custom releases in board reports. It's a
reflection on communities working together and being aware of this is
critical for the board I think. It shouldn't be a negative aspect
towards either community, there are good reasons why one community has
to go fast and one has to go slow.
- if they object, work to get the objections dealt with
- do a custom branch of the mina tree (you can `svn cp` parts
of the ASF repository into your own svn area easily
enough)
- change (project|pom).xml and similar files to have a
sensible artifact version
- create the MINA snapshot from your branch
- do not release or seperately distribute your snapshot, and
Is this possible if you're going to be a maven build? ie) there will
be a mina jar that qpid would need to depend on. If it's a maven build
(no idea what qpid uses); would they change the group id to be qpid's
id, or keep it as mina's?
add some documentation to discourage others from doing so as
needed
- include the MINA snapshot in your release candidate
- document the MINA's snapshot use and origin
- business as usual
- note the custom-built thingie (by reference probably) on
the VOTE thread for the podling release
How about package name? Should those be changed to avoid clashes with
official releases?
- note that doing this properly is often more work than just
doing the needed work within MINA, especially if you have a
good working relationship with that community already
Yep. Effectively you are taking on the role of release manager, so
it's going to be more effort doing it from scratch than in the
original place with local experts (even if they're inactive).
Great email Leo :)
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
