On 8/19/06, Wendy Smoak <[EMAIL PROTECTED]> wrote:
On 8/19/06, Craig McClanahan <[EMAIL PROTECTED]> wrote: > Wendy wrote: > > A non-SNAPSHOT version should be built exactly once if at all > > possible. Once it's in a repository, for all intents and purposes it > > *is* released and should not be changed. Next time around let's > > just evaluate the -SNAPSHOT version until it's ready to tag and > > release. > > Isn't that why we have a test repository for snapshots? Otherwise, you'd > only get one shot at publishing any particular version number, and we'd end > up with lots of holes in the sequence of version numbers ever actually > published. You can't have it both ways. :) Either we do test builds and discard them if necessary, or we build release candidates as 1.1.3-RC1, -RC2, etc.
Or, we train people who are evaluating test builds about what to do. But we should not be building and re-building (and deploying to a
public repository) anything that does not have a SNAPSHOT version number. We would never go back and 're-do' a release candidate, correct?
Agreed ... but evaluating release candidate bits (even if the sigs are posted) is *not* the same as evaluating the "here's the real bits". It puts too much trust in the release manager not to screw up the final process, if the vote is on a release candidate. On the other hand, if we're just interested in evaluating interim builds that *might* end up being a release, we can just keep updating the snapshots and say "please try again" ... iterate until satisfied ... without any special "candidate" markings at all. Taking the next bits out of order...
> I would prefer to see our release votes be about "these are the > exact bits that I want to push to the dist directory, and to ibiblio". Agreed. > The problem with evaluating the snapshots is we're trusting that nothing > goes wrong with the real build process after version numbers are updated in > the POMs. ... > We definitely don't want to be pushing test artifacts with non-SNAPSHOT > versions as a normal course of action, but in the roll-up to a release it > seems like the only way to do it. We review and fix the snapshots until we're happy with them. (For MyFaces, I insert the last-changed svn revision number in the distribution filename.) Then we change the version number, build and deploy it once as 1.1.3, and vote on that. If there's a problem, move on to the next version. Can you explain why you think "missing" version numbers will be a problem?
Several issues: * Perception. Skipping x.y.z release numbers is not a common practice across open source projects, and will create questions in some peoples's minds about what happened ... and maybe lead to doubts if the developers are really smart enough to be depended on. * Confusion. Think of all the bug reports that have been marked as "will be included in 1.0.3". We're *assuming* that people will understand that, if we skip 1.0.3 because of packaging issues in the test build, that 1.0.4 will include all of those changes. * More perception. We've stated publicly we're working on a 1.0.3 release. Skipping it, and doing a 1.0.4 instead, increases the perception that we never release what we say we're going to. It could be perceived as giving us an excuse to *never* release because we can't get the build right. * Mechanics. Admittedly nowhere near the amount of trouble that the previous issues are, but it's a bunch of extra work (editing poms, setting up JIRA version numbers, etc.), taking time that could be better spent getting the release out in the first place. Craig
> I'll look at it tomorrow afternoon, but I suspect renaming the files > > will be the easiest solution for 1.0.3. > I can live with that for this version. Sounds good. It's now tomorrow evening and I haven't had time yet. :( Thanks, -- Wendy
