I like the way freebsd guys handle this. http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/cvs-tags.html
They have a current branch which is the latest code, release tags gives you exact release when they released a new version. Thus you can chose to upgrade your operating system via binaries they provide from their ftp site or with the sources, to a release. Of course releases sometimes have bugs so they have a stable branch I believe it would be confusing to have vpopmail-5-3-28-release tag which has different sources than the 5.3.28 release on the web site. So you should have vpopmail-5-3-28-release tag and perhaps vpopmail-5-3 tag for updates over vpopmail-5-3-28-release and the default tag is the current(development) code. (it is represented with a dot . in freebsd cvs) Then you can do vpopmail-5-4 tag for the extensive changes and new features added over vpopmail-5-3 So you would automatically have a stable version and a development version in a few months. The vpopmail-5-3 would become stable when the bugfixes from users are done and new features goes into vpopmail-5-4 so it will be the development branch. What FreeBSD guys do is that they stop adding new features in current after a while. They only do bug fixes, lets say for 3 months. Then when they think the source is stable enough, they declare the new version as stable. I omitted the last number in tags and maybe you should drop the minor number because people really dont like to update every week for newer versions with little changes :) It just cause more trouble for many people who thinks the biggest number is the best. Then they get cold from vpopmail :) Evren On Wed, 10 Sep 2003, Tom Collins wrote: > On Wednesday, September 10, 2003, at 04:45 PM, Ken Jones wrote: > > Untill CVS is up and running, how would I go about > > packaging up a new release? > > CVS is up now. Please start with that code, as it includes a few > changes to the current tarball. > > I forgot to mention the following in my previous email: > > ----- > If you'd like to keep up with changes committed to CVS, you can > subscribe to vpopmail-cvs > <http://lists.sourceforge.net/mailman/listinfo/vpopmail-cvs>. > ----- > > > Would it be as simple as: > > 1) get the current tarball > > 2) apply changes to my local copy > > 3) test test test > > 4) tar up the package with a new version number > > 5) upload to source forge? > > With CVS (actual cvs commands in quotes), you should "checkout" the > vpopmail module from the vpopmail CVS repository, make your changes to > your checked out version, and "commit" those changes (with a note > explaining what they're for). Whenever you start working on the > source, be sure to "update" your copy from the repository. You can > "diff" your copy with the current repository copy to see where changes > are. Or get the "status" on a file (or all files). > > I look to others with more experience than I for how to build releases. > My understanding is that when we have a stable version of vpopmail in > CVS, we'll tag it with a name like "vpopmail-5-3-28-release" (periods > aren't allowed in tags). Then, go to another directory and do a cvs > "export" to get the files as of that release tag, and tgz *that* up for > distribution. > > Ken, please go into the Admin section of the vpopmail project and take > a look at the File Releases section. Maybe once we're ready for a > release, we can get on the phone and I'll talk you though the process. > > -- > Tom Collins > [EMAIL PROTECTED] > QmailAdmin: http://qmailadmin.sf.net/ Vpopmail: http://vpopmail.sf.net/ > Info on the Sniffter hand-held Network Tester: http://sniffter.com/ > > >
