From rb-pdx-pm at redcat.com Mon Sep 10 12:16:47 2001 From: rb-pdx-pm at redcat.com (Tom Phoenix) Date: Wed Aug 4 00:05:23 2004 Subject: PDX Perl Mongers September meeting Tuesday Message-ID: Just a reminder: The PDX (Portland) Perl Mongers' meeting is Tuesday evening (tomorrow!), starting around 6. Bridgeport Brew Pub 1313 NW Marshall Street Portland, Oregon 97209 Let me know if you need the full announcement. Hope to see you there! -- Tom Phoenix Perl Training and Hacking Esperanto Randal Schwartz Case: http://www.rahul.net/jeffrey/ovs/ TIMTOWTDI From rb-pdx-pm at redcat.com Tue Sep 11 13:50:33 2001 From: rb-pdx-pm at redcat.com (Tom Phoenix) Date: Wed Aug 4 00:05:23 2004 Subject: PDX Perl Mongers' meeting postponed Message-ID: I regret to announce that the PDX Perl Mongers' meeting scheduled for today will be postponed due to today's tragedy. I'll send something to the list when we're ready to reschedule. -- Tom Phoenix Perl Training and Hacking Esperanto Randal Schwartz Case: http://www.rahul.net/jeffrey/ovs/ TIMTOWTDI From tkil at scrye.com Tue Sep 18 01:30:02 2001 From: tkil at scrye.com (Tkil) Date: Wed Aug 4 00:05:23 2004 Subject: status of postponed 2001-09-11 meeting? Message-ID: greetings. masque originally sent me the meeting posting for last tuesday's meeting, but i didn't take the hint and join the mailing list, so i didn't see the cancellation. well, consider the hint taken. i found him on irc a few hours later, and he said that the meeting had been postponed. has a new date/time been set for it? i'm visiting from colorado, and i thought it would be interesting to meet some perl geeks up here. i would have just waited to see what would pop up on the mailing list, but (1) i'm a slug, and didn't join until this evening; (2) i have no idea what kind of traffic to expect on this list, so i wasn't sure how long i'd have to wait; and (3) one week was a plausible postponement, so i wanted to see if the meeting was tomorrow evening (tuesday, 2001-09-18). thanks, t. TIMTOWTDI From todd_caine at eli.net Tue Sep 18 16:09:45 2001 From: todd_caine at eli.net (Todd Caine) Date: Wed Aug 4 00:05:23 2004 Subject: Release Management? Message-ID: <3BA7B819.E32C14EC@eli.net> Does anyone have any pointers on good information regarding software release management using CVS? I'm trying to figure out best practices for releasing and managing large amounts of unrelated software. Todd Caine TIMTOWTDI From todd_caine at eli.net Wed Sep 19 10:54:17 2001 From: todd_caine at eli.net (Todd Caine) Date: Wed Aug 4 00:05:23 2004 Subject: Release Management Message-ID: <3BA8BFA9.92D0F14F@eli.net> Ok, I'll be a bit more specific. I am trying to figure out best practices for managing software in a team environment. Currently we are using CVS for revision control. There is no defined way to release software, besides cutting a formal release via CVS and tar'ing it up. I just finished a project and have created a release in CVS. I then exported the software to a directory in /tmp where I built a Solaris package. Should the package stream be checked into the repository as well? Should it be under the same CVS module? Even after I cut a formal release (branch and base tags)? Does anyone have any suggestions for selecting version numbers? Are README and CHANGES files sufficient for proper documentation? I guess I'm just not aware of how release management is done in other shops. Any feedback would be greatly appreciated. Thanks, Todd Caine TIMTOWTDI From todd_caine at eli.net Wed Sep 19 12:59:09 2001 From: todd_caine at eli.net (Todd Caine) Date: Wed Aug 4 00:05:23 2004 Subject: Release Management References: <3BA8BFA9.92D0F14F@eli.net> Message-ID: <3BA8DCED.2D90AD13@eli.net> Just in case anyone else is interested...... The Terminator Rat wrote: Hi, Todd. I've read a few books and done release management for a few projects, but I wouldn't say I'm an expert. Like my friend Kelly Russell once said, "I'm not an actor, but I play one on T.V.". You should *not* check in the Solaris package, since it is merely a way of repackaging the repository's sources. However, you probably want to make a "release" target in your Makefile or a "mk_release" script that builds the package for you. This will ensure that you can recreate the package with the same arguments and files at a later date. Be sure to specify the sources by name (don't just use '*.pl', for instance) so that the file list in the package will be consistent. You should use branches to manage bug-fixes and other mods on released software. Don't forget to baseline each branch, or you'll have trouble pulling up the fixes to the mainline. When building your package, you want to create a virgin source tree and populate it with CVS export. For instance: rm -rf build mkdir build cvs export -d build -r release_1_2_3 project cd build make release Of course, all of the above could be built into the 'release:' target in the Makefile or your mk_release script. Version numbering is more art than science (and pop art at that). The first official public release is usually 1.0, but that can vary. The defacto standard for version numbering is : major.minor.[p[patchlevel]] The patchlevel is typically bumped when a bug fix is made. The minor number is usually bumped when significant new functionality is added. A change in the major number usually indicates extreme changes from the previous version (i.e. a re-write or re-design). Don't forget that CVS doesn't allow you to use '.' in symbolic or branch tags -- substitute them with '_' characters. For example, release 1.2.3 becomes "release-1_2_3". When I was doing release management on the PIX, we bumped the software from 3.4 to 4.0 because Checkpoint had bumped Firewall1's major number. The differences between the two "major" versions was minimal, but the marketing department thought it was something of a coup. Not that I'm suggesting doing this, but it's a good illustration that version numbering isn't entirely a technical issue. Keeping README and CHANGES files is often sufficient for documenting the changes made to the release. You can generate the CHANGES file after the fact if necessary. An easy way to do this is to browse through the commit history since the last release. Alternatively, create a diff against the previous release and note the changes made. Obviously this is much more time-intensive, but you'll catch things that didn't make it into the commit history (and miss things that did). To go back on my word above, you may wish to keep a directory somewhere in the repository that contains the packaged software for each release. For instance, create a 'dists' module and check in each new distribution file. Be sure to turn off keyword expansion ('cvs add -kb') on the distfiles to prevent them being corrupted by RCS keyword expansion. Check them in with the name they were distributed by (i.e. 'foo-1.2.3.tar.gz'). This is much more useful in the long run than patching the previous binary. Another very cool and handy thing you can do is add build information to the binary so you can identify the exact rev and build of the software at a later date. A common way to do this is to build a target into your Makefile that updates build information in the package. There's a good example of adding build information in the Jufitsu sources -- in particular, look at how the Makefile runs newvers.sh to create vers.c. A similar thing would be very simple in Perl. The following is quite handy in Perl for single-script programs: use vars qw/ $VERSION /; my $REVISION = '$Revision: 1.67 $'; ($VERSION) = $REVISION =~ m/: (\S+)\ \$$/; Then you can arrange for your script to print the version if requested. In this case, you are making the script's version an identity with the file's revision number. The RCS $Name$, $Author$ and $Date$ strings could also be used to build up a build/release information string. Probably the two most useful things you can do are to create and maintain a CHANGES file, and automate the release process as much as possible. In an ideal world, after getting the green-light from your testers, you would just "make release" and hand the package to whoever does your distribution (i.e. your FTP site, mail it out on CD-ROM's, etc). Hope that helps, -r On Wed, 19 Sep 2001, Todd Caine wrote: > I am trying to figure out best practices for managing software in a team > environment. Currently we are using CVS for revision control. There is no > defined way to release software, besides cutting a formal release via CVS > and tar'ing it up. I just finished a project and have created a release in > CVS. I then exported the software to a directory in /tmp where I built a > Solaris package. Should the package stream be checked into the repository > as well? Should it be under the same CVS module? Even after I cut a formal > release (branch and base tags)? Does anyone have any suggestions for > selecting version numbers? Are README and CHANGES files sufficient for > proper documentation? I guess I'm just not aware of how release management > is done in other shops. Any feedback would be greatly appreciated. > > Thanks in advance. > Todd > . > ==================================================================== > = GEekList -- GeEk oF thE WorLd UniTed -- Techie forum = > ==================================================================== > . > -- O----O Karl F. Schilke - rat at cynical dot org - http://www.cynical.org/~rat \oO/ ==\/== "If I was just half the man he is ... I'd probably fall over." TIMTOWTDI From tkil at scrye.com Wed Sep 19 14:14:46 2001 From: tkil at scrye.com (Tkil) Date: Wed Aug 4 00:05:23 2004 Subject: Release Management In-Reply-To: <3BA8BFA9.92D0F14F@eli.net> References: <3BA8BFA9.92D0F14F@eli.net> Message-ID: >>>>> "Todd" == Todd Caine writes: Todd> Ok, I'll be a bit more specific. I am trying to figure out Todd> best practices for managing software in a team environment. there are probably many many books and web pages on this topic. what have you happened across so far? Todd> Currently we are using CVS for revision control. There is Todd> no defined way to release software, besides cutting a formal Todd> release via CVS and tar'ing it up. most larger environments i've been in have used a few other components as well: * a bug-tracking system. i've used bugzilla and ddts. there's also gnats. * a program to extract a coherent set of version numbers, based on which bug numbers have been fixed in those versions. it has to be able to check for "sandwiched" bugs, too. the only system like this that i ever worked with was a home-brew perl4 monstrosity. in this environment, every check-in must have a bug number in the comments. you can then go through the comments and figure out which versions fix which bugs. (or, you can do it "mozilla-style": the head version is always the one that is taken for every build -- but the tree is built continuously, and any breakage is taken seriously. large modifications are done on branches, then merged ("landed") all at once.) Todd> I just finished a project and have created a release in CVS. I Todd> then exported the software to a directory in /tmp where I built Todd> a Solaris package. Should the package stream be checked into Todd> the repository as well? Should it be under the same CVS module? Todd> Even after I cut a formal release (branch and base tags)? i'd just keep the package (with a release number and/or date either on the filename, or in the file -- the package system probably has this). keep it in an archive somewhere, and back it up carefully. (of course, that's true for the active code repository as well.) Todd> Does anyone have any suggestions for selecting version numbers? do you mean release numbers? the most common scheme i've seen is probably major.minor.patchlevel; patchlevels fix bugs, minors add features, majors are rewrites (and usually imply a non-forward- compatible change in functionality). if you're asking "which versions of the individual files do we grab for a given build", then the answer is the script i mentioned above, or something similar. you can do this by hand, if the team is small and disciplined enough. each person tags the components that they're responsible for, and then you yank out every file with that tag. Todd> Are README and CHANGES files sufficient for proper Todd> documentation? documentation for whom? users? administrators/installers? future maintainers? each of these groups has different documentation requirements. remember that the documentation needs to be under source control, too, and checked in with the same controls as the code base is. Todd> I guess I'm just not aware of how release management is done in Todd> other shops. Any feedback would be greatly appreciated. hopefully this has given you some ideas. i'd like to see more feedback, too, although a perl-specific list is probably too limiting for this; look into joining some of the source-control or configuration-management discussions (should be linkend off various web sites.) t. TIMTOWTDI