You are viewing a plain text version of this content. The canonical link for it is here.
Posted to repository@apache.org by robert burrell donkin <rd...@apache.org> on 2005/09/12 23:32:05 UTC
snapshots policy...?
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.
AIUI the right place for unofficial releases is
http://cvs.apache.org/repository. i uploaded the jar but it doesn't seem
to have been mirrored to the maven repository on ibiblio.
is this directory mirrored?
is this process the right one to make jar's available to maven users?
cheers
- robert
Re: snapshots policy...?
Posted by robert burrell donkin <rd...@apache.org>.
On Tue, 2005-09-13 at 19:55 -0700, Phil Steitz wrote:
> Steve Loughran wrote:
> > On 9/13/05, robert burrell donkin <rd...@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.
it does invite dependencies but at least is gives us some measure of
control and influence over them. the arguments against releasing with
unreleased dependencies are strong and i think we'd have a good chance
of convincing others of this.
> >>>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?
the key is that we don't want to encourage anyone creating releases
against snapshots whether from apache or elsewhere. we have this rule in
the commons and it has been proved a very good discipline.
> 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.
IMHO this is has more to do with the quality of the execution of the
snapshots than the innate nature of snapshots. it would be good to have
some guidelines describing the limitations and problems with snapshots
together with how to execute in a way that minimizes them.
> > 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 isn't unreasonable to ask people to add cvs.apache.org to their list
of repositories.
but history has proved that if we were to strictly enforce the internal
only rule, then snapshots would find their way onto the public repos
without any apache influence. by providing an apache channel we may be
able to exercise some measure of influence.
> >>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 :-)
release management is the time consuming part and that requires an
apache committer (though a pmc'er is preferred). at the moment, getting
a commons release out (even of code in a good state) probably takes a
month from start to finish. IMHO a lot of this is down to the higher
standards of current releases and this isn't something i'd be happy to
sacrifice...
> > 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.
+1
> >>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.
IMHO the crucial point is that the cvs.apache.org repository should not
not an internal repository but a temporary one for unstable code. use of
binaries to allow continued development (until the next release) is
reasonable but no other project should rely on it for releases since it
will be removed when the next full release is cut. this would mean that
there would still be pressure to create frequent releases but that it
wouldn't stop ongoing development of code elsewhere.
does this sound like a reasonable policy?
> 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.
your part in pushing the standards of releases higher in the commons is
nothing to be ashamed about.
IMHO maturity plus fear of loss of reputation implies infrequent
releases. the quality of commons releases is now pretty good and
maintaining that quality takes time and effort. i'm very glad that you
(and others) invest the time required to produce high quality releases.
i'd rather have fewer better releases than a lot of poor ones.
> 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.
i'm a big fan of that release system but IMHO it wouldn't work well for
the commons.
- robert
Re: snapshots policy...?
Posted by Phil Steitz <ph...@steitz.com>.
Steve Loughran wrote:
> On 9/13/05, robert burrell donkin <rd...@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
Re: snapshots policy...?
Posted by Steve Loughran <st...@gmail.com>.
On 9/13/05, robert burrell donkin <rd...@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.
>
> > 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?
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. 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.
>
> 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).
-steve
Re: snapshots policy...?
Posted by robert burrell donkin <rd...@apache.org>.
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.
> 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.
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.
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.
> Others may disagree, but as a Jakarta PMC member, I would -1
> public release of commons snapshots to the apache mirrors or ibiblio.
i can see the bandwidth issue for the public mirrors. i can also see
that it's reasonable to ask people to add cvs.apache.org to their list
of repositories.
but IMHO removing all old snapshots (say) once a new release is cut
should be enough encouragement to upgrade and would be better than
telling users that they should roll their own.
- robert
Re: snapshots policy...?
Posted by Phil Steitz <ph...@steitz.com>.
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. 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. Others may disagree, but as a Jakarta PMC member, I would -1
public release of commons snapshots to the apache mirrors or ibiblio.
Phil
Re: snapshots policy...?
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Tuesday 13 September 2005 06:22, Carlos Sanchez wrote:
> That's the correct process, but it's not mirrored to ibiblio. The user
> has to add http://cvs.apache.org/repository to the list of
> repositories.
And the reason is that ibiblio is a "no deletes" system, and snapshots should
be considered temporary solutions. cvs.apache.org may get cleaned up of
snapshots in the future.
Cheers
Niclas
Re: snapshots policy...?
Posted by Carlos Sanchez <ca...@apache.org>.
Hi,
That's the correct process, but it's not mirrored to ibiblio. The user
has to add http://cvs.apache.org/repository to the list of
repositories.
Regards
On 9/12/05, robert burrell donkin <rd...@apache.org> 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.
>
> AIUI the right place for unofficial releases is
> http://cvs.apache.org/repository. i uploaded the jar but it doesn't seem
> to have been mirrored to the maven repository on ibiblio.
>
> is this directory mirrored?
>
> is this process the right one to make jar's available to maven users?
>
> cheers
>
> - robert
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (GNU/Linux)
>
> iD8DBQBDJfPU1TNOdbExPeIRArBRAJ4npodghtqteKo+y7pujOlq2BEsIgCcCrEB
> bUClswaMccwtdFqDhWU4M4c=
> =YgxD
> -----END PGP SIGNATURE-----
>
>
>