Re: VERSION and VCS
* Johan Vromans [EMAIL PROTECTED] [2008-07-09 17:10]: What are the alternatives? You probably want to use git-describe in your build script. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: VERSION and VCS
Jim Schneider [EMAIL PROTECTED] writes: This should be handled by your release building tool (a feature that seems an obvious no-brainer, once it's been pointed out that it's missing). Yes, and no. In general, a package has a version associated. For this version number the release building tool is a good way to have it incremented. But for all the individual modules that are part of a package? Their version numbers should only increase when something changed, i.e., at commit time. Not at release time. A task very neatly handled by CVS. And for which GIT c.s. has no alternative. -- Johan
Re: VERSION and VCS
Johan Vromans wrote: But for all the individual modules that are part of a package? Their version numbers should only increase when something changed, i.e., at commit time. Not at release time. Let me speak against this. I find non-uniform version numbers a pain. Version 123 of Foo::Bar::Baz is associated with what version of Foo::Bar? Arggh!
Re: VERSION and VCS
Hello, I prefer the individual package versioning too. What I have experienced over time is that single packages sometimes are separated out into separate distributions and due to the nature of the Perl package name spacing, a version number should be at least present. Nothing speaks against not doing this until actual separation time, but I must admit I prefer packages having separate life cycles and version history since a distribution is just a matter of packaging and upon installation, distributions do seem to dissolve into the filesystem as separate packages only related in their coupling. jonasbn On 11/07/2008, at 18.07, Elliot Shank wrote: Johan Vromans wrote: But for all the individual modules that are part of a package? Their version numbers should only increase when something changed, i.e., at commit time. Not at release time. Let me speak against this. I find non-uniform version numbers a pain. Version 123 of Foo::Bar::Baz is associated with what version of Foo::Bar? Arggh! -- pauseid: JONASBN email: [EMAIL PROTECTED] blog: http://use.perl.org/~jonasbn/journal/
Re: VERSION and VCS
On Fri, Jul 11, 2008 at 10:57 AM, Johan Vromans [EMAIL PROTECTED] wrote: But for all the individual modules that are part of a package? Their version numbers should only increase when something changed, i.e., at commit time. Not at release time. A task very neatly handled by CVS. And for which GIT c.s. has no alternative. I disagree. For one, as Elliot pointed out, it's a royal pain to figure out which version of a module goes with which version of another module in the same distro. Also, multiple modules in the same distro tend to depend on each other of course, so their functionality can change in subtle or not-so-subtle ways even if their code doesn't. I prefer slapping an identical version number on every .pm file in the distribution. -Ken
Re: VERSION and VCS
On Wed, Jul 9, 2008 at 8:09 AM, Johan Vromans [EMAIL PROTECTED] wrote: The CPAN indexer requires perl modules (and sub-modules) to have a non-descending VERSION number. RCS/CVS $Revision$ has been invaluable for that. Not really. If you use RCS/CVS numbers, then you have several problems: 1. Various files in the distribution have different version numbers, so it's harder to be sure a user has the right version of each one 2. Commits made during the course of development get version numbers that do not correspond to a release, so it looks like you have missing releases 3. Major vs minor releases should increment different parts of the version number, and doing that at commit time doesn't match the reality of the release process. Because of these issues I feel it's best to just update the version numbers when a release is made. You might as well do this by hand, since you need to update the README, CHANGES, etc. files at the same time. Now more and more development is migrating towards VCS that do not have such a feature (git, svn, hg, ...). Probably a good thing, since it forces people to move away from arbitrary and meaningless release numbers. What are the alternatives? Manually updating the version numbers of changed modules before a release does not sound appealing to me. I know we like things to be automated, but for reasons I mention above, I think this is really the best way anyway. I ususally get the advice to build a hook script, etc., but I think this 'problem' should be dealt with at a non-individual level. If it's going to be automated it would still require the person doing the release to make a choice about the version number, update the CHANGES and README, etc.
Re: VERSION and VCS
Supposed to tag revisions with a version number for a release. So you have version n is the set of revision numbers of various components. But nobody says you have to put the revision numbers in a version statement. You can just keep them in a comment Sent from my BlackBerry® smartphone with Nextel Direct Connect -Original Message- From: Bill Ward [EMAIL PROTECTED] Date: Fri, 11 Jul 2008 14:58:06 To: Johan Vromans[EMAIL PROTECTED] Cc: module-authors@perl.org Subject: Re: VERSION and VCS On Wed, Jul 9, 2008 at 8:09 AM, Johan Vromans [EMAIL PROTECTED] wrote: The CPAN indexer requires perl modules (and sub-modules) to have a non-descending VERSION number. RCS/CVS $Revision$ has been invaluable for that. Not really. If you use RCS/CVS numbers, then you have several problems: 1. Various files in the distribution have different version numbers, so it's harder to be sure a user has the right version of each one 2. Commits made during the course of development get version numbers that do not correspond to a release, so it looks like you have missing releases 3. Major vs minor releases should increment different parts of the version number, and doing that at commit time doesn't match the reality of the release process. Because of these issues I feel it's best to just update the version numbers when a release is made. You might as well do this by hand, since you need to update the README, CHANGES, etc. files at the same time. Now more and more development is migrating towards VCS that do not have such a feature (git, svn, hg, ...). Probably a good thing, since it forces people to move away from arbitrary and meaningless release numbers. What are the alternatives? Manually updating the version numbers of changed modules before a release does not sound appealing to me. I know we like things to be automated, but for reasons I mention above, I think this is really the best way anyway. I ususally get the advice to build a hook script, etc., but I think this 'problem' should be dealt with at a non-individual level. If it's going to be automated it would still require the person doing the release to make a choice about the version number, update the CHANGES and README, etc.
Re: VERSION and VCS
Bill Ward wrote: Because of these issues I feel it's best to just update the version numbers when a release is made. You might as well do this by hand, since you need to update the README, CHANGES, etc. files at the same time. Well, not exactly by hand, but initiated by hand, yes. Perl::Version/perl-reversion are great for this.
VERSION and VCS
The CPAN indexer requires perl modules (and sub-modules) to have a non-descending VERSION number. RCS/CVS $Revision$ has been invaluable for that. Now more and more development is migrating towards VCS that do not have such a feature (git, svn, hg, ...). What are the alternatives? Manually updating the version numbers of changed modules before a release does not sound appealing to me. I ususally get the advice to build a hook script, etc., but I think this 'problem' should be dealt with at a non-individual level. What are your ideas? -- Johan
Re: VERSION and VCS
# from Johan Vromans # on Wednesday 09 July 2008 08:09: Now more and more development is migrating towards VCS that do not have such a feature (git, svn, hg, ...). What are the alternatives? Just use the integer time()? Manually updating the version numbers of changed modules before a release does not sound appealing to me. Use the `perl-reversion` tool? Is that too manual? The build tool should probably do this for you, but does it bump the version numbers just before rolling the release or several commits before? Right after a release? When does it commit and tag? What about the Changes file? I've been thinking immediately after a release is the time to bump the version -- but what about when you decide that it is a major version bump? That seems like it would almost always be a 'manual' decision. Of course, if you're using the $Revision$, that doesn't have a 'major/minor' number on svn, so it is basically just a slow-moving version of time(), right? --Eric -- We who cut mere stones must always be envisioning cathedrals. --Quarry worker's creed --- http://scratchcomputing.com ---
