Or... if ye don't like that... why not _use four numbers_ and make the rule be that for a three number release you must call a vote....
Of course that would involve fixing DefaultArtifactVersion.compareTo.... -Stephen On Wed, Aug 13, 2008 at 1:25 PM, Stephen Connolly < [EMAIL PROTECTED]> wrote: > Well let's change that. > > Hudson has shown, MANY relases made FREQUENTLY is better than fewer. > > Could we have a public staging repo... and have the rule that to deploy to > this repo you don't need a vote... to promote from that repo to repo1 you > need the vote. > > Then, we just roll relases to the stanging repo as we develop rather than > having to call votes (which is a higher barrier) > > If that means that repo1 has maven-foo-plugin version 2.0.7 and 2.0.983 and > nothing inbetween because nobody called a vote... I say fine > > -Stephen > > On Wed, Aug 13, 2008 at 1:20 PM, nicolas de loof <[EMAIL PROTECTED]>wrote: > >> The option is to allow timestamp for SNAPSHOT dependencies, considering >> the >> timestamp jar will not be updated as a SNAPSHOT would, and so the build >> get's reproductible ... until the snapshot repo gets cleaned ! >> >> The idea is interesting as we hardly get plugin releases, and have no >> roadmap for them, so a project that requires a bug fix has no other option >> >> >> 2008/8/13 Stephen Connolly <[EMAIL PROTECTED]> >> >> > Oooooh! there's an option to allow snapshot dependencies in release? >> Cool! >> > I did not know that... Now I can go cause me a heap load of trouble! >> > >> > On Wed, Aug 13, 2008 at 1:14 PM, nicolas de loof <[EMAIL PROTECTED]> >> > wrote: >> > >> > > Would you DEPLOY a snapshot without first testing and commiting ? >> > > >> > > You're right that this is not a 100% safe way to fix this issue, just >> an >> > > attempt to make things (a little bit) more stable. >> > > A full fix would be to never use SNAPSHOTs, and to deprecate >> > > release/enforcer option to accept them ;-) >> > > >> > > 2008/8/13 Stephen Connolly <[EMAIL PROTECTED]> >> > > >> > > > Of course the problem with that is what if there were local changes >> > when >> > > > the >> > > > build was made? Now the SCM revision is meaningless >> > > > >> > > > On Wed, Aug 13, 2008 at 1:03 PM, nicolas de loof < >> [EMAIL PROTECTED]> >> > > > wrote: >> > > > >> > > > > Recent snapshot repository purge introduced issues for those of us >> > that >> > > > > depend on a specific timestamp SNAPSHOT. This is supposed to be a >> > valid >> > > > > usecase as supported by the release and enforcer plugins. >> > > > > >> > > > > There is no way to rebuild such jars, as we can get the sources >> from >> > > SCM >> > > > > according to date, but cannot build and deploy the jar with the >> > > expected >> > > > > name (manual renaming is required). >> > > > > >> > > > > Could we consider for future the option to use the SCM revision ( >> for >> > > SCM >> > > > > that support this option, but most of us use SVN ;-) ) in >> replacement >> > > to >> > > > a >> > > > > timestamp, so that a specific timestamp can easily be rebuilded at >> > > > anytime >> > > > > ? >> > > > > The version format could be "X.Y.Z-revision-ABCDE". >> > > > > >> > > > > Nicolas. >> > > > > >> > > > >> > > >> > >> > >
