On Sep 29, 2010, at 11:25 AM, Brett Porter wrote: > > On 29/09/2010, at 11:57 PM, Jason van Zyl wrote: > >> >> On Sep 29, 2010, at 9:50 AM, Brett Porter wrote: >> >>> Hi, >>> >>> The release plugin has a mode where it can assist you in updating snapshot >>> dependencies at release time. A lot of this is better manipulated with the >>> versions plugin now, but it seems a useful feature to have at release time >>> if you can. >>> >> >> I honestly don't know why this was ever added. Allowing people to leave >> snapshots in releases just leads to bad things. >> >> Exactly how does this work? In order for it to be reproducible you not only >> have to flip the snapshots to releases but if you ever gave this to a user >> you need to have a tag for what you're including. I don't think the support >> is that sophisticated and let's someone do a half-assed release that is >> likely not to be reproducible. >> >> Why don't we just remove this capability and simplify the process. Release >> all dependencies or you don't release. End of story. > > That's what it does - it still fails if there are snapshots. It gives you the > option if it finds a snapshot to let you change that to a released version.
What's the use case here? You have a snapshot of log4j and there's a release version you can use? POM says 2.0-SNAPSHOT but 2.0 is available? > So rather than puking out, making you go and adjust the snapshot, then coming > back and trying again, you can do it at the time when you type in the other > versions. > > The weird bit is that it used to then flip the dependency back to a snapshot > after the release, even though it's outside the project. I'm suggesting it > change the default to keep it as the release you just pinned it to. > >> >>> The previous behaviour was a bit weird, though. It would prompt you like >>> this: >>> >>> Resolve Project Dependency Snapshots.: 'test:MRELEASE-583' set to release? >>> (yes/no) yes: : >>> What is the next development version? (2.1.3-SNAPSHOT) 2.1.3-SNAPSHOT: : >>> >>> The first question was redundant - you'd already said you wanted to update >>> snapshots and the other option is failure. The second one assumes you'll be >>> setting the snapshot to the equivalent release, then automatically to the >>> next dev't version. The inflexibility of the first part was pointed out in >>> MRELEASE-583 and I applied a change similar to the patch provided. >>> >>> However, I disagree with the default choice of updating the dependency to >>> another snapshot - since this is outside of the reactor it's a better >>> practice to pin to the release you just chose. I retained one exception for >>> the use case where it was a more recent snapshot than the release you >>> selected, and the original choice is restored. >>> >>> As it's only interactive and the form of the questions change, I don't >>> think this will catch anyone by surprise, and encourages better practices. >>> >>> Does anyone see a downside? >>> >>> - Brett >>> >>> -- >>> Brett Porter >>> [email protected] >>> http://brettporter.wordpress.com/ >>> >>> >>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >> >> Thanks, >> >> Jason >> >> ---------------------------------------------------------- >> Jason van Zyl >> Founder, Apache Maven >> http://twitter.com/jvanzyl >> --------------------------------------------------------- >> >> What matters is not ideas, but the people who have them. Good people can fix >> bad ideas, but good ideas can't save bad people. >> >> -- Paul Graham >> >> >> > > -- > Brett Porter > [email protected] > http://brettporter.wordpress.com/ > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl --------------------------------------------------------- A language that doesn’t affect the way you think about programming is not worth knowing. -— Alan Perlis
