Mailing-List: contact repository-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: repository@apache.org
Received-SPF: pass (asf.osuosl.org: domain of steve.loughran@gmail.com
 designates 64.233.184.196 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=ZO8HnLPiVcXBUQDfl7Ml753+6DMHevhW0can9eHVRrhV7hGW9+tczDnP8b3qHCHLJIGTmIRErqm4kFOZ1tYjmML0nV3ak8NYzMvoaOKiFqphXN9d8Lb7YDKVL/gm9FNfs/EoN+orAx4qQ0AeeoSOBJs3fcoGJpGZY0UULfPaF1Y=
Message-ID: <c84a5078050913144967a4e1e1@mail.gmail.com>
Date: Tue, 13 Sep 2005 22:49:49 +0100
From: Steve Loughran <steve.loughran@gmail.com>
Reply-To: steve.loughran@gmail.com
To: repository@apache.org
Subject: Re: snapshots policy...?
In-Reply-To: <1126644413.5099.21.camel@knossos.elmet>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <1126560725.8796.7.camel@knossos.elmet>
	 <43266ACC.6010508@steitz.com> <1126644413.5099.21.camel@knossos.elmet>

On 9/13/05, robert burrell donkin <rdonkin@apache.org> wrote:
> On Mon, 2005-09-12 at 22:59 -0700, Phil Steitz wrote:
> > robert burrell donkin wrote:
> > > a user requested that a (dated) snapshot of a commons library be
> > > uploaded to ibiblio for use by mavenized projects. i've never done th=
is
> > > before so i thought i'd give it a go.
> >
> > I would have objected on commons-dev if I knew the intention was to pus=
h
> > this out to ibiblio. IMHO, we should *not* be encouraging dependencies
> > on non-released jars, nor publishing them to mirrored sites.
>=20
> this is an argument which has been going on for a number of years now
> and i can see both sides. i used to dislike snapshots (and i still
> dislike undated SNAPSHOTs) but i can now see the difficulties for open
> source projects that needs features now which might take many months to
> appear in a full release.

Maybe, but does that mean that OSS projects should release stuff based
on nightly snapshots of other prokects.

>=20
> > The "internal use" repository at cvs.apache.org should just be used for
> > apache projects that need to use snapshots internally.  External users
> > should be encouraged to depend on released versions of commons
> > components.
>=20
> IMHO there is quite a difference between end users and the case of other
> open source projects under active development.

dependencies propagate.

I got burned last month by a project (muse) that released stuff based
on snapshots of other things. Because of that action, it is impossible
for me to rebuild their image, because even if their stuff is all
labelled in SVN, the libraries they used arent tagged.

Do you think the projects used as snapshots really want to field
requests from end users "a nightly build from three months ago is
broken", that came about because some other project released using
snapshots?

Nobody should be releasing apps based on snaphots. Interim snapshots,
maybe, but not official point releases. Maybe you can use snapshot
stuff in the build process, but even then I'm dubious, because it
raises the barrier to development. (I say that, even though I use
ant1.7alpha+maven-2.0 tasks snapshot for our sourceforge-hosted
project, but only on side bits and then I keep the tasks under our
SCM)

>=20
> it seems a little unreasonable (to me) to say that it's fine to upload
> for the internal use of apache projects but that it's not alright to
> upload jars for the use of other open source projects. it also seems a
> little unreasonable to ask another open source project to wait until the
> next release (which may well be many months) for a some functionality
> they contributed back to the main library.

Any project can use the cvs.apache.org repository; I do it in our
smartfrog project, the order being

-SCM repository
-ibiblio
-cvs.apache.org

Just keeping it separate makes it clear things are less stable.

>=20
> IMHO all that this encourages is the proliferation of unofficial forked
> versions cut by people outside apache.
=20
> IIRC one of the major reasons why apache wanted to move the master
> repository back onto apache hardware (from ibiblio) is that we wanted to
> regain control over releases. i'm not sure that strictly enforcing the
> rule about internal use only would further this policy.

I'm against internal use only too. But think we need to emphasise that
no projects should release stuff using the internals if they can help
it. I also think that no apache projects shoudl release stuff that
depends on snapshots, which is now the effective policy of the WS PMC
(after my muse experience).
=20

-steve