Re: Who should use SNAPSHOT when? RE: The Future of the Release Process.
On 1/2/07, Dan Fabulich <[EMAIL PROTECTED]> wrote: Wendy Smoak wrote: > On 12/22/06, Dan Fabulich <[EMAIL PROTECTED]> wrote: > > > > From: Kenney Westerhof [mailto:[EMAIL PROTECTED] > > > > > > If I understand correctly, the problem is that a 'staged' release > > > still contains a SNAPSHOT keyword in the metadata/filename? > > > > Yes, that's the problem. > > I would agree, but that's not how I understand staging to work at all. > > The Apache projects I work on like to vote on the *exact* artifacts > that will be released to the public, so the staged release must not > have a -SNAPSHOT qualifier. I realize now that I agreed with Kenney too soon. The problem is, really, the existence of a -SNAPSHOT qualifier at all, which, in turn, forces us to jump through hoops at the last second in the release process in order to remove that qualifier. (-SNAPSHOT has some advantages, but for many organizations, the disadvantages are considerably more significant.) The real point here is that the "staging" process (which creates non-SNAPSHOT binaries that have not yet been released) should be something that we could use throughout the development cycle, not some special last-minute thing that provides special last-minute binaries. The way to do that is to provide build numbers on non-SNAPSHOT releases, allowing us to bless a release binary without modifying it (for example, by moving it from one repository to another). That's essentially what Eclipse does... While developing to a 3.3 release, each bundle in every build gets a version qualifier (e.g. 3.3.0.v20061116) which is incremented if the bundle changes. The eventual 3.3 release will then just be a collection of bundles with the latest qualifier for each. As an example, these are some off the bundles in the 3.2.1 release. Note that some bundles that never changed still have the 3.2.0.v version. org.eclipse.core.boot_3.1.100.v20060603.jar org.eclipse.core.commands_3.2.0.I20060605-1400.jar org.eclipse.core.contenttype_3.2.0.v20060603.jar org.eclipse.core.expressions_3.2.1.r321_v20060721.jar org.eclipse.core.filebuffers_3.2.1.r321_v20060721.jar org.eclipse.core.filesystem.win32.x86_1.0.0.v20060603.jar org.eclipse.core.filesystem_1.0.0.v20060603.jar org.eclipse.core.jobs_3.2.0.v20060603.jar org.eclipse.core.resources.compatibility_3.2.0.v20060603.jar org.eclipse.core.resources.win32_3.2.0.v20060603.jar org.eclipse.core.resources_3.2.1.R32x_v20060914.jar org.eclipse.core.runtime.compatibility.auth_3.2.0.v20060601.jar org.eclipse.core.runtime.compatibility.registry_3.2.1.R32x_v20060907 org.eclipse.core.runtime.compatibility_3.1.100.v20060603.jar org.eclipse.core.runtime_3.2.0.v20060603.jar org.eclipse.core.variables_3.1.100.v20060605.jar More info at http://wiki.eclipse.org/index.php/Version_Numbering Tom -Dan ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Who should use SNAPSHOT when? RE: The Future of the Release Process.
Wendy Smoak wrote: > On 12/22/06, Dan Fabulich <[EMAIL PROTECTED]> wrote: > > > > From: Kenney Westerhof [mailto:[EMAIL PROTECTED] > > > > > > If I understand correctly, the problem is that a 'staged' release > > > still contains a SNAPSHOT keyword in the metadata/filename? > > > > Yes, that's the problem. > > I would agree, but that's not how I understand staging to work at all. > > The Apache projects I work on like to vote on the *exact* artifacts > that will be released to the public, so the staged release must not > have a -SNAPSHOT qualifier. I realize now that I agreed with Kenney too soon. The problem is, really, the existence of a -SNAPSHOT qualifier at all, which, in turn, forces us to jump through hoops at the last second in the release process in order to remove that qualifier. (-SNAPSHOT has some advantages, but for many organizations, the disadvantages are considerably more significant.) The real point here is that the "staging" process (which creates non-SNAPSHOT binaries that have not yet been released) should be something that we could use throughout the development cycle, not some special last-minute thing that provides special last-minute binaries. The way to do that is to provide build numbers on non-SNAPSHOT releases, allowing us to bless a release binary without modifying it (for example, by moving it from one repository to another). -Dan ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Who should use SNAPSHOT when? RE: The Future of the Release Process.
On 22 Dec 06, at 10:03 PM 22 Dec 06, Craig McClanahan wrote: On 12/22/06, Wendy Smoak <[EMAIL PROTECTED]> wrote: On 12/22/06, Dan Fabulich <[EMAIL PROTECTED]> wrote: > > From: Kenney Westerhof [mailto:[EMAIL PROTECTED] > > > > If I understand correctly, the problem is that a 'staged' release > > still contains a SNAPSHOT keyword in the metadata/filename? > > Yes, that's the problem. I would agree, but that's not how I understand staging to work at all. The Apache projects I work on like to vote on the *exact* artifacts that will be released to the public, so the staged release must not have a -SNAPSHOT qualifier. Agreed. When I vote on a release, I'm always saying "show me the bits." In this scenario, it would be nice for the release plugin to have an option to copy approved artifacts from the staging area to the release area (along with corresponding signatures and metadata updates) *without* any modification to the artifacts themselves. Yes, that's what we have just tried with a Geronimo release where the actual release was staged, Geronimo folks votes and then I merged the artifacts into the central syncing directory on Apache using Tom's new repository copier which takes into account merging the necessary metadata. Jason. -- Wendy Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Who should use SNAPSHOT when? RE: The Future of the Release Process.
On 22 Dec 06, at 9:45 PM 22 Dec 06, Wendy Smoak wrote: On 12/22/06, Dan Fabulich <[EMAIL PROTECTED]> wrote: > From: Kenney Westerhof [mailto:[EMAIL PROTECTED] > > If I understand correctly, the problem is that a 'staged' release > still contains a SNAPSHOT keyword in the metadata/filename? Yes, that's the problem. I would agree, but that's not how I understand staging to work at all. The staging directory would container artifacts as they would be released in the wild. No SNAPSHOTs, and in the form they would be merged into the central repository. Jason. The Apache projects I work on like to vote on the *exact* artifacts that will be released to the public, so the staged release must not have a -SNAPSHOT qualifier. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Who should use SNAPSHOT when? RE: The Future of the Release Process.
On 12/23/06, Craig McClanahan <[EMAIL PROTECTED]> wrote: On 12/22/06, Wendy Smoak <[EMAIL PROTECTED]> wrote: > > On 12/22/06, Dan Fabulich <[EMAIL PROTECTED]> wrote: > > > > From: Kenney Westerhof [mailto:[EMAIL PROTECTED] > > > > > > If I understand correctly, the problem is that a 'staged' release > > > still contains a SNAPSHOT keyword in the metadata/filename? > > > > Yes, that's the problem. > > I would agree, but that's not how I understand staging to work at all. > > The Apache projects I work on like to vote on the *exact* artifacts > that will be released to the public, so the staged release must not > have a -SNAPSHOT qualifier. Agreed. When I vote on a release, I'm always saying "show me the bits." In this scenario, it would be nice for the release plugin to have an option to copy approved artifacts from the staging area to the release area (along with corresponding signatures and metadata updates) *without* any modification to the artifacts themselves. I wrote the repositorytools plugin in mojo-sandbox for this reason. It has goals to copy a specific artifact (including signatures) or an entire remote repository to another repository, while merging the necessary repository metadata. This is still work-in-progress although Jason already tested it (I think it was on a Geronimo release ). Tom -- > Wendy Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Who should use SNAPSHOT when? RE: The Future of the Release Process.
On 12/22/06, Wendy Smoak <[EMAIL PROTECTED]> wrote: On 12/22/06, Dan Fabulich <[EMAIL PROTECTED]> wrote: > > From: Kenney Westerhof [mailto:[EMAIL PROTECTED] > > > > If I understand correctly, the problem is that a 'staged' release > > still contains a SNAPSHOT keyword in the metadata/filename? > > Yes, that's the problem. I would agree, but that's not how I understand staging to work at all. The Apache projects I work on like to vote on the *exact* artifacts that will be released to the public, so the staged release must not have a -SNAPSHOT qualifier. Agreed. When I vote on a release, I'm always saying "show me the bits." In this scenario, it would be nice for the release plugin to have an option to copy approved artifacts from the staging area to the release area (along with corresponding signatures and metadata updates) *without* any modification to the artifacts themselves. -- Wendy Craig
Re: Who should use SNAPSHOT when? RE: The Future of the Release Process.
On 12/22/06, Dan Fabulich <[EMAIL PROTECTED]> wrote: > From: Kenney Westerhof [mailto:[EMAIL PROTECTED] > > If I understand correctly, the problem is that a 'staged' release > still contains a SNAPSHOT keyword in the metadata/filename? Yes, that's the problem. I would agree, but that's not how I understand staging to work at all. The Apache projects I work on like to vote on the *exact* artifacts that will be released to the public, so the staged release must not have a -SNAPSHOT qualifier. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Who should use SNAPSHOT when? RE: The Future of the Release Process.
Comments inline... Brett Porter wrote: > Does this cover the whole topic? > http://docs.codehaus.org/display/MAVENUSER/BEA+Maven+Requirement+Documen ts I'd say that highlights a lot of the most important requirements; it's probably best read together with the blog article as well. http://darkforge.blogspot.com/2006/12/compass-as-compared-with-mavens.ht ml > I think it's all good - as long as it is all built on top of the > stuff we already have (including what Joakim is proposing). It will > probably require changes to many aspects of Maven (packaging, > dependency resolution, deployment and release). It will also touch on > Continuum and Archiva, I imagine. > > Is this right? I would say so. -Dan ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Who should use SNAPSHOT when? RE: The Future of the Release Process.
Comments inline... > -Original Message- > From: Kenney Westerhof [mailto:[EMAIL PROTECTED] > Sent: Thursday, December 14, 2006 5:07 AM > To: Maven Developers List > Subject: Re: Who should use SNAPSHOT when? RE: The Future of the Release > Process. > > Hi, > > If I understand correctly, the problem is that a 'staged' release still > contains a SNAPSHOT keyword in the metadata/filename? Yes, that's the problem. [Even the filename is a problem when you know the files will be installed in the context of a larger assembly installed on end-users' desktops. More generally, I think, most professional closed source ISVs have it as a requirement that you can't go around renaming libraries right before you release your software; if they don't make this a requirement, IMO they should.] > Also, how would you see snapshot 'releases' without a snapshot keyword? > If there's no indicator (timestamp?) in the filename, you'll overwrite the > previous deployed versions, which is bad. You keep them in separate directories. http://darkforge.blogspot.com/2006/12/compass-as-compared-with-mavens.ht ml The most important change I suggest here is to modify the way we "deploy" builds to include a "build number" directory in the repository layout; every deployed artifact (even released artifact) would be in its own build number directory, so they would never clobber each other. The official "release vote" would be to vote on promoting a particular build number to a release. > Personally I'm pro release-candidate marking of artifacts. I don't have an opinion about release-candidate marking in *general*, but it should be at least possible to have a release process in Maven that doesn't "mark" release candidates at all (even in the filename). > What if maven understood the difference between the version in the pom > and the version in the filename? Whatever comes of this discussion, I hope it emerges that the point you raise here is an essential part of the answer: some part of what you might conventionally call the "version number" (whether that's a timestamp, build number, or the release status) needs to not appear in the POM, even (especially) for released binaries. -Dan ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Who should use SNAPSHOT when? RE: The Future of the Release Process.
OK, I've finally written up the Compass way of doing things. I've got it as a blog article for easier reading (and HTML formatting), but I'm also including the text below. http://darkforge.blogspot.com/2006/12/compass-as-compared-with-mavens.ht ml In this article, I'll describe some of the differences between Maven 2.x and the "Compass" internal home-grown system we use at work. I'll first describe our repository layout, then describe our component descriptor file, and finally I'll summarize some of the advantages and disadvantages of using the different systems and suggest future work. The Compass system was designed with Maven 1.x in mind. The original developers had said, roughly: "You know, Maven's got the right idea, but this really hasn't been implemented the way we'd want it. We should rewrite it ourselves from scratch." REPOSITORY LAYOUT Like Maven, Compass has one or more remote repositories containing official built artifacts, (or "components", as we call them,) as well as a local repo on each developer's machine which caches artifacts from the remote repo and contains locally built artifacts. Where Maven and Compass substantially diverge is in how artifacts are stored in the repository. While Compass doesn't have a notion of "groupId", our remote repository is divided up into sections, like this: thirdparty/ log4j/ junit/ firstparty/ RECENT/ foo/ bar/ INTERNAL/ foo/ bar/ RELEASE/ foo/ bar/ [NOTE: This isn't exactly how it looks, but it's close enough.] Within a given section, you find a flat list of components. In this example, "foo" and "bar" are buildable components that we've created; log4j and junit are, naturally, components built by other people. "RECENT" contains only freshly built components. "INTERNAL" contains components that have been blessed by some human being, and are intended for internal consumption. "RELEASE" contains released components and products. In practice, there are 914 components in RECENT and 671 components in INTERNAL. Within a given component directory, you'll find a number of subdirectories, which define the "version" of the component. Thirdparty versions may have any arbitrary strings for their names (e.g. "3.8.1" "1.0beta3" "deerpark"). However, firstparty versions are strictly defined: they are simply the P4 Changelist number of the product at the time it was built. (A quick note about changelist numbers as opposed to revision numbers. Most people are familiar with the distinction between CVS revision numbers and SVN revision numbers: CVS revision numbers are "per file" whereas SVN revision numbers are global to the repository. P4 changelist numbers are like SVN revision numbers. [Also note that you can calculate something like an SVN revision number in CVS, simply by noting the timestamp of the most recent check-in.]) So, within the "foo" directory in RECENT, you'll see this: foo/ 123456/ foo.jar 123457/ foo.jar 123458/ foo.jar @LATEST -> 123458 That's three numbered directories with a "LATEST" symlink, pointing to the most recent build in that directory. The first thing to note about this system is that if you build 123458 and then rebuild 123458, it will replace the old "123458" directory. The second thing to note is that if you change foo at all, it will get a new changelist/revision number, and so it will get a new subdirectory under "foo" once automatically built. The three sections within the "firstparty" directory (RECENT, INTERNAL, RELEASE) are called "release levels", and we have a process about how components move into each release level. "foo" and "bar" are automatically built every night and deployed into RECENT; if there are more than three builds in RECENT, we automatically delete the oldest build. If somebody thinks that a build of "foo" is good enough to keep around, they "promote" that build into INTERNAL by simply copying the numbered changelist directory into INTERNAL. Once we think it's good enough to release, we can promote that INTERNAL build into RELEASE by copying it there. There is no tool, nor any need for a tool, to rebuild for release or make even the slightest changes to the released binaries. Especially note that we don't put any of this information in the filename of the jar. It's called "foo.jar" whether it's in RECENT, INTERNAL, or RELEASE. We do burn the changelist number of foo.jar into its META-INF/manifest.mf at build-time... that information remains constant whether "foo.jar" is copied to INTERNAL or RELEASE. COMPONENT DESCRIPTOR FILE Compass has a file that looks a lot like the Maven POM XML file... our file is called "component.xml". component.xml defines a list of elements. Here's an example component.xml file: foo 6.1.0 main bar 2.1.x
Re: Who should use SNAPSHOT when? RE: The Future of the Release Process.
Does this cover the whole topic? http://docs.codehaus.org/display/MAVENUSER/BEA+Maven+Requirement +Documents I think it's all good - as long as it is all built on top of the stuff we already have (including what Joakim is proposing). It will probably require changes to many aspects of Maven (packaging, dependency resolution, deployment and release). It will also touch on Continuum and Archiva, I imagine. Is this right? - Brett On 14/12/2006, at 2:46 PM, Jason van Zyl wrote: Hi Dan, I think what you are describing is what you do at your work place, and I think it might be good if you could give us a full description of your system for folks here to help them understand exactly what it is you're talking about. I probably know a little more about it then most here but I still don't entirely grok the workflow you're describing. Maybe some simple examples of how artifacts names would change through the workflow you're describing versus our current approach would be helpful. Anything that makes releases easier is a good thing. Thanks, Jason. On 13 Dec 06, at 10:11 PM 13 Dec 06, Dan Fabulich wrote: Thanks for a great e-mail Joakim. I wanted to chime in with my two cents... (I've been off the radar for a couple of months while waiting for permission to sign my ICLA; it's in now, and I'm now back to paying more careful attention to this process... forgive me if some of this has already been covered.) One of the goals I know we've expressed before (but not explicitly listed here) is that Maven's release process should "lead by example": other projects (whether open-source or closed-source) who haven't put as much thought into release engineering as we have should look to us as an example of the "right way to do it". IMO, the requirements around "SNAPSHOT" releases is an important difference between open-source requirements for the release process and closed-source requirements... In this e-mail I want to describe an alternative release process (overlapping with the one Joakim described) that never uses "SNAPSHOT" and which is more appropriate to some organizations, perhaps especially closed-source ones. I think we all agree that it's "bad" (at least a little bit) to change things at the last minute before release (whether it be source code, binaries, or even your build process); one goal of the updated release process is that we should make as few last-minute changes as possible, and, to the greatest extent possible, "bless binaries". But so long as you have the word "SNAPSHOT" embedded into your JARs during development, you'll have to change *something* at the last second, if only to remove the word "SNAPSHOT". There is another way, which is better for at least some groups some of the time. If you never used "SNAPSHOT", but Maven enforced a requirement that all JARs would have build numbers embedded in them (not appearing in the file name, but appearing in JAR manifest.mf and in the deployed POM), then the release process could be as little as copying the JARs into the right place and updating some metadata to call them released. Here's another way of saying the same thing. The release process Joakim described goes like this: a) Call vote b) Wait on approval. c) Collect release information. c) 'prepare' release (occurs once) d) 'stage' release (occurs 1 or more times) e) Wait on consensus from PMC for blessed artifacts. f) 'bless' release (occurs once) As this is described, it sounds as if projects would normally spend extremely little time in step D, "stage". But if Maven provided more complete build numbering support for non-SNAPSHOT builds, you could imagine the project spending their entire development life in step D. After step E a decision was made to release, in step F the blessing would occur, and development would immediately begin on 1.1 in step D... no period of time spent in "SNAPSHOT", so you wouldn't need to modify your code ("prepare") right before release. Although I've highlighted one big advantage of not marking code under development as "SNAPSHOT", the most significant disadvantage of doing it this way is that end users might confuse "SNAPSHOT" releases with the real official thing. (Perhaps especially if users just copy the relevant jars out of the repository and then leave Maven behind.) This can result in unnecessary support questions from users as they (unwittingly) complain about bugs in unreleased code, and can complicated support diagnostics as the person providing support may believe that the end-user has version 1.4, when they really have a developer snapshot of 1.4, never intended for release. With that said, I think most closed-source software development organizations don't have anywhere near as much fear of end-users grabbing under-development code and calling for support, since those binaries are typically kept a secret; in that c
Re: Who should use SNAPSHOT when? RE: The Future of the Release Process.
Hi, If I understand correctly, the problem is that a 'staged' release still contains a SNAPSHOT keyword in the metadata/filename? Also, how would you see snapshot 'releases' without a snapshot keyword? If there's no indicator (timestamp?) in the filename, you'll overwrite the previous deployed versions, which is bad. Personally I'm pro release-candidate marking of artifacts. Either you have a '1.0-' release candidate version/file, or '1.0-rc1'. Doesn't really matter except that -rcX is more human readable. All snapshot deployments of artifacts could then be seen as release candidates/staged artifacts. What if maven understood the difference between the version in the pom and the version in the filename? You could deploy a release candidate with -rc1 (or timestamp) in the filename. This file will never change. The POM itself mentions the version without the -rc1. Then all you have to do when promoting a staged release to a real release is move the files to another directory (one without -SNAPSHOT or -rcX in the name), and rename the files in the process. No file contents have to be changed. You can never get access to that release candidate unless you specify '-rc1' in the version tag of dependencies on that artifact. Example of the repo structure to clarify things: groupId/ foo/ 1.0-rc1/ foo-1.0-rc1.jar foo-1.0-rc1.pom ( tag here says '1.0') 1.0/ ... bar/ 1.0-rc1/ bar-1.0-rc1.jar bar-1.0-rc1.pom ( tag here says '1.0') 1.0/ ... For projects apart from foo and bar that depend on this artifact, this works (comparable to SNAPSHOT artifacts). For dependencies of the rc artifact, it won't, unless you release per artifact: Assume both foo and bar are in the same release cycle, and foo depends on bar. The foo pom cannot be changed when released, so it's on bar has to specify 1.0-rc1. This is a problem. But easily resolved: groupId/ foo/ 1.0/ maven-metadata.xml The metadata file mentiones that 1.0 is not released yet, and lists all release candidates. So when resolving bar-1.0 from foo, the metadata file is consulted and the 1.0-rc1 is used. The bad thing about this is that this works like SNAPSHOT resolution, except instead of specifying '1.0-SNAPSHOT' and getting '1.0-' you specify '1.0' and get the latest '1.0-rcX'. This is not necessarily a bad thing: if you want to promote foo, you also have to release bar. Maven should check if 1.0 is resolved to 1.0 or an rc before releasing. Also something could be done in maven internally to mark projects as non-final, since it knows when resolving 1.0 that it got an RC. The scheme above is almost identical to SNAPSHOT resolution. Differences: - no SNAPSHOT tag in the artifact files themselves - wheter something is a SNAPSHOT is determined from the absense of the artifact in the correct version dir (1.0 is a snapshot since 1.0/ doesn't contain foo-1.0.pom and the metadata file points to another version). If you look at a pom file that has no SNAPSHOT in there, you won't know for sure if it's a snapshot unless you check where it's resolved from. Normally this is never a problem - all artifacts are resolved from the local repo. When creating wars or other compound artifacts, or assemblies, the filenames should match the tag. For instance, assume foo is an ear project, embedding bar. If bar would be embedded as bar-1.0-rc1.jar, foo's contents would have to be changed on the final release because bar's filename would change, even though the version wouldn't. So when looking at a file bar-1.0.jar and the embedding pom you can only tell that it's a snapshot using the metadata file from groupId/bar/1.0/. Thoughts? Dan Fabulich wrote: Thanks for a great e-mail Joakim. I wanted to chime in with my two cents... (I've been off the radar for a couple of months while waiting for permission to sign my ICLA; it's in now, and I'm now back to paying more careful attention to this process... forgive me if some of this has already been covered.) One of the goals I know we've expressed before (but not explicitly listed here) is that Maven's release process should "lead by example": other projects (whether open-source or closed-source) who haven't put as much thought into release engineering as we have should look to us as an example of the "right way to do it". IMO, the requirements around "SNAPSHOT" releases is an important difference between open-source requirements for the release process and closed-source requirements... In this e-mail I want to describe an alternative release process (overlapping with the one Joakim described) that never uses "SNAPSHOT" and which is more appropriate to some organizations, perhaps especially closed-source ones. I think we all agree that it's "bad" (at least a little bit) to change things at the last minute before release (whether it be source code, binaries, or even your build process); one goal of the updated release process is that we should
Re: Who should use SNAPSHOT when? RE: The Future of the Release Process.
Hi Dan, I think what you are describing is what you do at your work place, and I think it might be good if you could give us a full description of your system for folks here to help them understand exactly what it is you're talking about. I probably know a little more about it then most here but I still don't entirely grok the workflow you're describing. Maybe some simple examples of how artifacts names would change through the workflow you're describing versus our current approach would be helpful. Anything that makes releases easier is a good thing. Thanks, Jason. On 13 Dec 06, at 10:11 PM 13 Dec 06, Dan Fabulich wrote: Thanks for a great e-mail Joakim. I wanted to chime in with my two cents... (I've been off the radar for a couple of months while waiting for permission to sign my ICLA; it's in now, and I'm now back to paying more careful attention to this process... forgive me if some of this has already been covered.) One of the goals I know we've expressed before (but not explicitly listed here) is that Maven's release process should "lead by example": other projects (whether open-source or closed-source) who haven't put as much thought into release engineering as we have should look to us as an example of the "right way to do it". IMO, the requirements around "SNAPSHOT" releases is an important difference between open-source requirements for the release process and closed-source requirements... In this e-mail I want to describe an alternative release process (overlapping with the one Joakim described) that never uses "SNAPSHOT" and which is more appropriate to some organizations, perhaps especially closed-source ones. I think we all agree that it's "bad" (at least a little bit) to change things at the last minute before release (whether it be source code, binaries, or even your build process); one goal of the updated release process is that we should make as few last-minute changes as possible, and, to the greatest extent possible, "bless binaries". But so long as you have the word "SNAPSHOT" embedded into your JARs during development, you'll have to change *something* at the last second, if only to remove the word "SNAPSHOT". There is another way, which is better for at least some groups some of the time. If you never used "SNAPSHOT", but Maven enforced a requirement that all JARs would have build numbers embedded in them (not appearing in the file name, but appearing in JAR manifest.mf and in the deployed POM), then the release process could be as little as copying the JARs into the right place and updating some metadata to call them released. Here's another way of saying the same thing. The release process Joakim described goes like this: a) Call vote b) Wait on approval. c) Collect release information. c) 'prepare' release (occurs once) d) 'stage' release (occurs 1 or more times) e) Wait on consensus from PMC for blessed artifacts. f) 'bless' release (occurs once) As this is described, it sounds as if projects would normally spend extremely little time in step D, "stage". But if Maven provided more complete build numbering support for non-SNAPSHOT builds, you could imagine the project spending their entire development life in step D. After step E a decision was made to release, in step F the blessing would occur, and development would immediately begin on 1.1 in step D... no period of time spent in "SNAPSHOT", so you wouldn't need to modify your code ("prepare") right before release. Although I've highlighted one big advantage of not marking code under development as "SNAPSHOT", the most significant disadvantage of doing it this way is that end users might confuse "SNAPSHOT" releases with the real official thing. (Perhaps especially if users just copy the relevant jars out of the repository and then leave Maven behind.) This can result in unnecessary support questions from users as they (unwittingly) complain about bugs in unreleased code, and can complicated support diagnostics as the person providing support may believe that the end-user has version 1.4, when they really have a developer snapshot of 1.4, never intended for release. With that said, I think most closed-source software development organizations don't have anywhere near as much fear of end-users grabbing under-development code and calling for support, since those binaries are typically kept a secret; in that case, the advantage of adding a "SNAPSHOT" marker may be outweighed by the disadvantage of requiring special changes right before release. Now that I've faxed in my ICLA, [heh] one of the goals I want to pursue as a Maven developer is to make the Maven release workflow support organizations that would want to work without ever using "SNAPSHOT": to make that "stage" step a workable healthy period in a product's lifecycle that software companies could spend most of their time in. Specifically, I thin