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. 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 >> br...@apache.org >> http://brettporter.wordpress.com/ >> >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> > > 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 br...@apache.org http://brettporter.wordpress.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
