www-repository mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <p...@steitz.com>
Subject Re: snapshots policy...?
Date Wed, 14 Sep 2005 02:55:00 GMT
Steve Loughran wrote:
> 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 this
>>>>before so i thought i'd give it a go.
>>>
>>>I would have objected on commons-dev if I knew the intention was to push
>>>this out to ibiblio. IMHO, we should *not* be encouraging dependencies
>>>on non-released jars, nor publishing them to mirrored sites.
>>
>>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.

This is a key point. By design, we (apache) have no control over what 
users do with our software.  Publishing snapshots invites dependencies 
on them.
> 
>>>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.
>>
>>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?

This is one of my concerns about commons. We have enough trouble 
supporting the released stuff by itself. It is a pain to reconstruct 
source for snapshots (even when tagged), in general there are no release 
notes, bugs aren't tracked against them, etc.
> 
> 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)
> 
> 
>>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. 

I guess I have always seen cvs.apache.org as an "internal" repo in the 
the following sense. What led to its getting set up, IIRC, was that both 
the directory and geronimo projects (then both in the incubator) had a 
large number of components that were being developed with some 
dependencies among them. An internal repo to share snapshots among 
apache projects seemed like a good idea and cvs.apache.org/repository 
was created.  What is "fine" about this is that we (apache) have control 
over what gets released and we can coordinate changes, etc.  This is how 
some companies use internal maven repos.

Once we start pushing these snapshots up to "public" repos, we lose 
control over when they "go away" and, more importantly, what may get 
released depending on them.

>>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.

They can always step up to help us get a real release out :-)  That's 
what other apache volunteers often do at commons :-)
> 
> 
> 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.

Another key point, which to me seems a reasonable compromise.
> 
> 
>>IMHO all that this encourages is the proliferation of unofficial forked
>>versions cut by people outside apache.
> 
>  
> 
>>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).
>  
I agree with the statement about not releasing our own software with 
snapshot dependencies.  I guess at the end of the day, I would not go so 
far as shutting off access to cvs.apache.org/repository from outside 
apache (partly because that would create problems for volunteers), but I 
think we need to maintain the distinction and warn users that the snaps 
*will* go away.

We should talk about commons in particular on commons-dev.  I agree that 
we need to get releases out quicker and I am as much to blame for 
current state as anyone else.  Maybe moving to the struts - tomcat - 
httpd release strategy could help us release with greater frequency. 
The mechanics are getting easier, but we can probably improve that as well.

Phil





Mime
View raw message