commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Steitz" <phil.ste...@gmail.com>
Subject [all] What is a release? WAS: [vote] releasing jci RC3 as 1.0 ...maybe this time?
Date Sun, 10 Jun 2007 17:22:02 GMT
On 6/10/07, Torsten Curdt <tcurdt@apache.org> wrote:
> >> So you are saying +1 for the assembly release ...but I don't get the
> >> "who needs what" part.
> >>
> >
> > What I meant was that I did not see it as a big user inconvenience to
> > bundle all of the jars into a single release, since they are
> > individually small.  So, yes, I am +1 on putting together an assembly
> > and making it available, along with the KEYS file, on the commons
> > download page.
>
> I just fear no one will use it ...but anyway.
>
Good question.  Two groups that I can think of.  First would be anyone
who repackages and/or builds larger distributions from source
including this component.  I think some Linux distros and other
repackagers use some of our components built from source.  IIRC this
has come up in the past.  I know some other OSS projects also build
from our released sources.  For example, Tomcat repackages parts of
[pool], [dbcp] and some others, building the repackaged classes from
our released source distributions.  In theory, they could do the same
from svn tags, but there is some loss of control in this case (see
below).

A second user group for the full distros is IT shops where full
buildable source and binaries are a requirement for OSS intruduction.
Forcing them to assemble their own source distros without hashes or
sigs associated with the sources would not be a welcome prospect.

> >> See above ...I think subversion is our source distribution. I don't
> >> really see a point in providing a classic source distribution. But
> >> maybe that's too much change for now ;)
> >
> > Yes, too much for me at least.  In theory, voting on a tag and
> > pointing users there to get sources still could be viewed as a
> > release, but that is a big change from current practice and
> > inconvenient for users who prefer to build from release sources.
>
> It is a big change ...but who says that changes are bad? ;)
>
Not me - change is good and it is good to talk about these things.
This one is a little dicey though because a) I don't like the idea of
not having signed sources as part of the distro and b) if not looked
at the right way it sort of seems like we are moving away from "open
source" and in violation of ASF release policy (from
http://www.apache.org/dev/release.html):

"The Apache Software Foundation produces open source software. All
releases are in the form of the source materials needed to make
changes to the software being released. In some cases, binary/bytecode
packages are also produced as a convenience to users that might not
have the appropriate tools to build a compiled version of the source.
In all such cases, the binary/bytecode package must have the same
version number as the source release and may only add binary/bytecode
files that are the result of compiling that version of the source code
release."

> But seriously: be realistic. Those people building the releases from
> will have subversion on their machine.
> And what can be simpler than a
> one-liner to checkout the sources? Even downloading it from an apache
> mirror is more work.
>
> > I think we should always distribute the source with our releases.
>
> I think the only problem that I am seeing is that tags are not
> immutable in svn. So in theory even a tag is not good enough but a
> release is really a revision number.
>
> > I guess what we are really talking about here is "what is a release?"
>
> True. Especially with maven2 as the build system. I tried to raise
> that a couple of times already. We need to come up with proper
> release instructions for maven2 based projects. This is for sure.
>
There we agree :-)

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message