Re: SVN snapshot versioning
Russ Allbery [EMAIL PROTECTED] wrote: In other words, use previous-version+svn-stuff if you're packaging that version plus some additional upstream modifications, and use next-version+svn-stuff if you're packaging an alpha or beta arelease ^ I hope you meant '~' here. of next-version. Well, you're free to do what you want with that. I gave my opinion, no need to repeat it. -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SVN snapshot versioning
Florent Rougon [EMAIL PROTECTED] writes: Russ Allbery [EMAIL PROTECTED] wrote: In other words, use previous-version+svn-stuff if you're packaging that version plus some additional upstream modifications, and use next-version+svn-stuff if you're packaging an alpha or beta arelease ^ I hope you meant '~' here. Yes, sorry. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SVN snapshot versioning
On Mon, 2007-01-22 at 19:51 -0500, Roberto C. Sanchez wrote: I disagree. How do I know that r91 was committed two days ago? This also does not hold for regular, released versions. I don't see why this should be conveyed in the version number of snapshot packages and not for regular releases: how fresh is version 2.1.8 of a package? Thijs signature.asc Description: This is a digitally signed message part
Re: SVN snapshot versioning
On Tue, Jan 23, 2007 at 01:39:30AM +0100, martin f krafft wrote: Why bother with the date? 2.1~svn-r91 seems much more concise and has the same information, really. Though you're right that the information is the same, a date is meaningful in spite of the knowledge of the revision control system (subversion in this case). The same can't be said for the SVN revision number. Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Re: SVN snapshot versioning
On Tue, 23 Jan 2007 09:56:28 +0100 Stefano Zacchiroli [EMAIL PROTECTED] wrote: On Tue, Jan 23, 2007 at 01:39:30AM +0100, martin f krafft wrote: Why bother with the date? 2.1~svn-r91 seems much more concise and has the same information, really. Though you're right that the information is the same, a date is meaningful in spite of the knowledge of the revision control system (subversion in this case). The same can't be said for the SVN revision number. As commented elsewhere, normal release numbers do not have any date component and you've still got the problem that multiple svn commits are frequently made on the same day. The date, in this context, is just misleading and would need to be a full UTC timestamp to have any real meaning. The revision number is far more precise and just like a normal 1:2.3.4-5 release string, you would need to refer to the upstream website(s) to determine the date of the release. The advantage of just using the svn 'r' number is that it makes this information available precisely and without duplication. Looking up that 'r' number not only tells you the date - just as looking up a normal release string would do - it also uniquely identifies the point at which the upstream code was packaged - again, just as a release string is intended to do. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgph0qPAuNJ1g.pgp Description: PGP signature
Re: SVN snapshot versioning
On Tue, 2007-01-23 at 09:56 +0100, Stefano Zacchiroli wrote: On Tue, Jan 23, 2007 at 01:39:30AM +0100, martin f krafft wrote: Why bother with the date? 2.1~svn-r91 seems much more concise and has the same information, really. Though you're right that the information is the same, a date is meaningful in spite of the knowledge of the revision control system (subversion in this case). The same can't be said for the SVN revision number. Also, in the (rare but can occur) event of a svn rollback, r91 is not necessarily accurate after the fact,whereas a datestamp is. -Rob -- GPG key available at: http://www.robertcollins.net/keys.txt. signature.asc Description: This is a digitally signed message part
Re: SVN snapshot versioning
On Tue, Jan 23, 2007 at 09:17:37AM +0100, Thijs Kinkhorst wrote: On Mon, 2007-01-22 at 19:51 -0500, Roberto C. Sanchez wrote: I disagree. How do I know that r91 was committed two days ago? This also does not hold for regular, released versions. I don't see why this should be conveyed in the version number of snapshot packages and not for regular releases: how fresh is version 2.1.8 of a package? True. However, when the package goes from version 2.1.8 to version 2.4.3, I have vague idea of how significant the change was, assuming the upstream developers follow half-way sane versioning practices. I know that sometimes a 0.0.1 increment can be a huge change and a major version increase can be something completely transparent to the user. However, with the svn repository version number, I have absolutely no idea of the magnitude of the changes. Perhaps freshness was not the best word. Anyhow, i still maintain that including the date is not at all harmful and can only help end users. Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: SVN snapshot versioning
On Tue, Jan 23, 2007 at 09:35:38AM +, Neil Williams wrote: As commented elsewhere, normal release numbers do not have any date component and you've still got the problem that multiple svn commits are frequently made on the same day. The date, in this context, is just misleading and would need to be a full UTC timestamp to have any real meaning. The revision number is far more precise and just like a normal I'm sorry, but I think this is bogus. For every one free software project that has a situation where the make multiple *significant* commits in a single calendar day, there are probably 100 which average less then a single commit per day or for which the last commit of the day is the most significant. The case you mention, I believe, is by far the exception and not the rule. 1:2.3.4-5 release string, you would need to refer to the upstream website(s) to determine the date of the release. The advantage of just using the svn 'r' number is that it makes this information available precisely and without duplication. Looking up that 'r' number not only tells you the date - just as looking up a normal release string would do - it also uniquely identifies the point at which the upstream code was packaged - again, just as a release string is intended to do. I see your point. Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: SVN snapshot versioning
On Tue, Jan 23, 2007 at 09:35:38AM +, Neil Williams wrote: As commented elsewhere, normal release numbers do not have any date component and you've still got the problem that multiple svn commits are frequently made on the same day. The date, in this context, is just misleading and would need to be a full UTC timestamp to have any real meaning. The revision number is far more precise and just like a normal My feeling is you're kinda nitpicking here, but let me play your game :) Unless you, as a Debian packager, are packaging a CVS/SVN/... snapshot whose date is today this is a bogus problem. Indeed if the date timestamp is at least yesterday [1] the amount of commit occurred until that day can no longer change. Using both CVS and SVN you can checkout/update your working copy up to that date without any possible confusion. Cheers. [1] i.e. yesterday or earlier in the time line -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Re: SVN snapshot versioning
On Tue, 23 Jan 2007 12:31:39 +0100 Stefano Zacchiroli [EMAIL PROTECTED] wrote: On Tue, Jan 23, 2007 at 09:35:38AM +, Neil Williams wrote: As commented elsewhere, normal release numbers do not have any date component and you've still got the problem that multiple svn commits are frequently made on the same day. The date, in this context, is just misleading and would need to be a full UTC timestamp to have any real meaning. The revision number is far more precise and just like a normal My feeling is you're kinda nitpicking here, but let me play your game :) Not really, I'm just feeding back on a real issue I faced with a previous project. Unless you, as a Debian packager, are packaging a CVS/SVN/... snapshot whose date is today this is a bogus problem. Not true. With an active project, there could be 100 commits on any one day. These happen at various times, from various timezones. You check out a revision for a specific point in time, it isn't obvious whether that includes revisions made in a different timezone. Even if you specify 00:00:00 to take the last commit of the day, it still isn't obvious whether that includes a commit from someone +0800 or -0700. The user needs to know your timezone or the timezone of the server which is even more obscure (and can change). Individual commits are not one-liners, many commits touch dozens of files. I've made commits that touched 30% of a 95Mb codebase in a single revision. I've made commits that changed 1 byte. I've made dozens of commits in one day, I've gone hundreds of days without any commits. I've been in projects where half a dozen developers in four different timezones all commit (more than once) to the same branch on the same 'day'. It is no surprise that active projects have svn revision numbers in six digits whilst still at release 2.0. Indeed if the date timestamp is at least yesterday [1] the amount of commit occurred until that day can no longer change. When looking backwards in the commit list, you still have the timezone problem - just because there can be no more changes on that date, does not change the fact that changes could easily have been made either side of midnight in your timezone that would be deemed the same day for someone in a different timezone. You end up having to specify a full UTC timestamp. Using both CVS and SVN you can checkout/update your working copy up to that date without any possible confusion. Not true. You cannot reliably ensure that a commit at 11:50:00 -0500 is actually part of your daily snapshot without specifying your timezone in the snapshot date, i.e. creating a full UTC timestamp in the version string. Many free software developers are most active in the evening (in their timezone) so this problem occurs frequently. The svn 'r' system is specifically designed to cope with this inadequacy of CVS - it is, IMHO, crazy to dump it for imprecise and inaccurate 'date' strings. Using a full UTC timestamp is even worse - far too messy. Looking up an 'r' number is as trivial as putting svn r12314 project into google. I really don't see what could possibly be easier. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpKPNxduxokV.pgp Description: PGP signature
Re: SVN snapshot versioning
On Tue, Jan 23, 2007 at 12:40:21PM +, Neil Williams wrote: Not true. You cannot reliably ensure that a commit at 11:50:00 -0500 is actually part of your daily snapshot without specifying your timezone in the snapshot date, i.e. creating a full UTC timestamp in the version string. Many free software developers are most active in the evening (in their timezone) so this problem occurs frequently. The svn 'r' system is specifically designed to cope with this inadequacy of CVS - it is, IMHO, crazy to dump it for imprecise and inaccurate 'date' strings. Using a full UTC timestamp is even worse - far too messy. Looking up an 'r' number is as trivial as putting svn r12314 project into google. I really don't see what could possibly be easier. Right. However, I think we are rapidly approaching overkill in this discussion. How about this: * the version string includes the date * the changelog mentions the exact rev No ambiguity. Someone interested in the source would (or should) have the wherewithal to look at the changelog or other documentation if he considers there to be some sort of ambiguity. Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: SVN snapshot versioning
On Tue, 23 Jan 2007 08:28:10 -0500
Roberto C. Sanchez [EMAIL PROTECTED] wrote:
The svn 'r' system is specifically designed to cope with this
inadequacy of CVS - it is, IMHO, crazy to dump it for imprecise and
inaccurate 'date' strings. Using a full UTC timestamp is even worse -
far too messy.
Looking up an 'r' number is as trivial as putting svn r12314 project
into google. I really don't see what could possibly be easier.
Right. However, I think we are rapidly approaching overkill in this
discussion. How about this:
* the version string includes the date
I still see no reason for any package built from svn to include the
date in any version string. It just makes it look like the DD doesn't
understand how SVN differs from CVS.
* the changelog mentions the exact rev
Wrong way around, IMHO. The ChangeLog normally includes dates, as does
debian/changelog ('changelog' is ambiguous in this context) - it may
include svn 'r' strings too but, primarily, ChangeLog uses dates and
debian/changelog does not support anything but dates as timestamps.
Take a look at gnucash - it outputs the svn 'r' number in the
splashscreen and in the Help:About. A snapshot of gnucash would
definitely need to use 2.0.2~r14542 - there's no place for a date when
the package itself declares itself by means of svn 'r' numbers.
It is trivial to retrieve the svn number from the checked out working
copy during the build and therefore make a completely automated
snapshot that incorporates the 'r12356' into any portion of the build.
--
Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
pgpaUWUss96V7.pgp
Description: PGP signature
Re: SVN snapshot versioning
On Tue, Jan 23, 2007 at 01:59:32PM +, Neil Williams wrote:
On Tue, 23 Jan 2007 08:28:10 -0500
Roberto C. Sanchez [EMAIL PROTECTED] wrote:
Right. However, I think we are rapidly approaching overkill in this
discussion. How about this:
* the version string includes the date
I still see no reason for any package built from svn to include the
date in any version string. It just makes it look like the DD doesn't
understand how SVN differs from CVS.
Right, and I would see it as the DD being superior to the user by
including something that might make no sense to the user.
* the changelog mentions the exact rev
Wrong way around, IMHO. The ChangeLog normally includes dates, as does
debian/changelog ('changelog' is ambiguous in this context) - it may
include svn 'r' strings too but, primarily, ChangeLog uses dates and
debian/changelog does not support anything but dates as timestamps.
I meant as an actual entry. Something like this:
* updated to r4387 from svn
Take a look at gnucash - it outputs the svn 'r' number in the
splashscreen and in the Help:About. A snapshot of gnucash would
definitely need to use 2.0.2~r14542 - there's no place for a date when
the package itself declares itself by means of svn 'r' numbers.
If that is the pattern used by upstream, that is fine. I think lots of
proprietary software packages do that as well. Something like version
2.0.1.5236, where 5236 represents a way to identify the exact revision
in the developer's source control system. Of course, most show the
version without that to avoid confusing users.
It is trivial to retrieve the svn number from the checked out working
copy during the build and therefore make a completely automated
snapshot that incorporates the 'r12356' into any portion of the build.
I don't see how this makes things easier for the end user. By the end
user, I mean someone who is just interested in getting and installing a
package. Somebody wanting to customize/recompile/whatever will be able
to figure it out.
Regards,
-Roberto
--
Roberto C. Sanchez
http://people.connexer.com/~roberto
http://www.connexer.com
signature.asc
Description: Digital signature
Re: SVN snapshot versioning
I suggest we settle this discussion, having clarified the sorting rules and possibilities, and voiced our preferences. In the end, the maintainer should do what s/he wants and be prepared to handle the consequences. As long as there are no epochs needed, it likely won't matter at all. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems arthur slapped his arms about himself to try and get his circulation a little more enthusiastic about its job. -- hitchhiker's guide to the galaxy signature.asc Description: Digital signature (GPG/PGP)
Re: SVN snapshot versioning
Andrew Donnellan [EMAIL PROTECTED] wrote: So for a snapshot of revision 91 between stable version 2.0 and future version 2.1, would something like: 2.1~20070123svn.r91 be OK? Ah, so now that we have this '~' allowed by dpkg, we have to use it everywhere? You cannot predict the future. It might me that next version is not 2.1 as you expected, but, e.g., 3.0. Why not base your version number on things you *know* for sure: that the last released version was 2.0? Therefore, I'd suggest something like 2.0+20070123svn.r91 (or without the date, for those who don't like it---personally, I find it useful, even if not atomic-precise; OK, since some of you want to nitpick with timezones here, the correct solution while keeping the date would be more like 2.0+svn.r91.20070123, to ensure that package versions are sorted based on the SVN revision and not the date). This has two more advantages: - '+' has a somewhat intuitive meaning here (which '~' definitely doesn't have): what you're packaging is version 2.0 plus (enhanced with) some more changes that are found in SVN revision 91, which was commited about 2007-01-23. - works with older dpkg. -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SVN snapshot versioning
On Tue, 23 Jan 2007 18:08:00 +0100, Florent Rougon [EMAIL PROTECTED] said: Andrew Donnellan [EMAIL PROTECTED] wrote: So for a snapshot of revision 91 between stable version 2.0 and future version 2.1, would something like: 2.1~20070123svn.r91 Ah, so now that we have this '~' allowed by dpkg, we have to use it everywhere? No, but we should use it in situations for which is was specifically designed for, no? You cannot predict the future. It might me that next version is not 2.1 as you expected, but, e.g., 3.0. Why not base your version number on things you *know* for sure: that the last released version was 2.0? This is massively confused. If you name your version 2.1~20070123svn.r91, and the next veriosn is 2.1, 3.0 or 4090009009, the transition from the current version to the future version will work. The only future version which won't work is a version that compares lower than 2.1 (like, 2.1~~), so the suggestion is valid. manoj -- Klatu barada nikto. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SVN snapshot versioning
Neil Williams [EMAIL PROTECTED] writes: On Tue, 23 Jan 2007 08:28:10 -0500 Roberto C. Sanchez [EMAIL PROTECTED] wrote: The svn 'r' system is specifically designed to cope with this inadequacy of CVS - it is, IMHO, crazy to dump it for imprecise and inaccurate 'date' strings. Using a full UTC timestamp is even worse - far too messy. Looking up an 'r' number is as trivial as putting svn r12314 project into google. I really don't see what could possibly be easier. Right. However, I think we are rapidly approaching overkill in this discussion. How about this: * the version string includes the date I still see no reason for any package built from svn to include the date in any version string. It just makes it look like the DD doesn't understand how SVN differs from CVS. This is in the eyes of the beholder. It does not really tell anything about DDs/developers abilities. The date is very informative measure for live projects that are packaged frequently. For the end user downloading these two packages is very different: foo-1.0~r145 foo-1.0~20070122-r145 The first thing is techical and has meaning for the upstream and possibly for the DD packager only. The second one adds information for the end user who downloads and installs the package to the system telling how fresh this snapshot is. He does not care about the VC system that the upstream uses. The benefit of the latter is the best of both worlds: - Exact indication of the point of revision (r145) - Approximate information of the date when the snapshot was made The timestamp can also serve both DD and end user to remind if he needs to check for new updates. The regular release syntax: foo-1.1.tar.gz is in fact uninformative. The project may have disappeared long gone and notbody would not know without digging up some more information. Including date never hurts. It even helps sorting packages in correct order easily. Jari -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SVN snapshot versioning
also sprach Manoj Srivastava [EMAIL PROTECTED] [2007.01.23.1738 +]: You cannot predict the future. It might me that next version is not 2.1 as you expected, but, e.g., 3.0. Why not base your version number on things you *know* for sure: that the last released version was 2.0? This is massively confused. If you name your version 2.1~20070123svn.r91, and the next veriosn is 2.1, 3.0 or 4090009009, the transition from the current version to the future version will work. The only future version which won't work is a version that compares lower than 2.1 (like, 2.1~~), so the suggestion is valid. Please reread his point, because it'a a good one. Say 2.0 is based on r90, and r91 comes out with an important patch, then snapshot 2.0+svn-r91 and not 2.1~svn-r91. If you do the latter, you're screwed if 2.0.1 comes out next. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems 'oh, that was easy,' says Man, and for an encore goes on to prove that black is white and gets himself killed on the next zebra crossing. -- douglas adams, the hitchhiker's guide to the galaxy signature.asc Description: Digital signature (GPG/PGP)
Re: SVN snapshot versioning
Manoj Srivastava [EMAIL PROTECTED] wrote: Ah, so now that we have this '~' allowed by dpkg, we have to use it everywhere? No, but we should use it in situations for which is was specifically designed for, no? Precisely. And it was *not* designed for CVS/SVN/whatever RCS snapshots. AFAIK, it was designed for Release Candidates, which are well-known for exhibiting this problem: 1.0 1.0rc1 This is massively confused. Sorry, not at all. Besides what Martin explained, using 2.1 in your version number without knowing for sure that 2.1 is going to be the next release is ugly, even if it were harmless (which is not the case). Better use something you do know: if this SVN snapshot is based on 2.0, then use 2.0. -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SVN snapshot versioning
On 1/24/07, martin f krafft [EMAIL PROTECTED] wrote: also sprach Manoj Srivastava [EMAIL PROTECTED] [2007.01.23.1738 +]: You cannot predict the future. It might me that next version is not 2.1 as you expected, but, e.g., 3.0. Why not base your version number on things you *know* for sure: that the last released version was 2.0? This is massively confused. If you name your version 2.1~20070123svn.r91, and the next veriosn is 2.1, 3.0 or 4090009009, the transition from the current version to the future version will work. The only future version which won't work is a version that compares lower than 2.1 (like, 2.1~~), so the suggestion is valid. Please reread his point, because it'a a good one. Say 2.0 is based on r90, and r91 comes out with an important patch, then snapshot 2.0+svn-r91 and not 2.1~svn-r91. If you do the latter, you're screwed if 2.0.1 comes out next. I suppose if you're using a snapshot of SVN trunk it will be fixed there as well, so you don't need to change the version number. Anyway in my case upstream's releases are always confused, with 2.0beta1 referred to as '2.0' or '2.0 beta' and beta 2 also referred to as '2.0 beta', etc. and as far as I know the next version will be at least 2.1. Even if 2.0 is officially released I don't necessarily want to package it. -- Andrew Donnellan ajdlinuxATgmailDOTcom (primary)ajdlinuxATexemailDOTcomDOTau (secure) http://andrewdonnellan.com http://ajdlinux.wordpress.com [EMAIL PROTECTED] hkp://subkeys.pgp.net 0x5D4C0C58 http://linux.org.auhttp://debian.org Get free rewards - http://ezyrewards.com/?id=23484 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SVN snapshot versioning
Florent Rougon [EMAIL PROTECTED] writes: Sorry, not at all. Besides what Martin explained, using 2.1 in your version number without knowing for sure that 2.1 is going to be the next release is ugly, even if it were harmless (which is not the case). Better use something you do know: if this SVN snapshot is based on 2.0, then use 2.0. Yes, you should pick the form of the version number based on your knowledge, or lack of knowledge, about what the next version will be. Usually this is fairly straightforward if you're following upstream development. If upstream just released 2.0 and has since committed more patches, so you want to package a snapshot, then call it 2.0+svn-rNNN or by date or whatever you prefer. If upstream is preparing 2.1 and you're packaging a snapshot of what is or will be the release branch, then use 2.1~svn-rNNN. In other words, use previous-version+svn-stuff if you're packaging that version plus some additional upstream modifications, and use next-version+svn-stuff if you're packaging an alpha or beta arelease of next-version. In practice, this is almost never ambiguous. In the few cases where upstream manages to make themselves and everyone else horribly confused, well, that's what epochs are for. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SVN snapshot versioning
On Tue, Jan 23, 2007 at 10:40:03AM +1100, Andrew Donnellan wrote: Hi mentors, I'm currently creating a package for the Jabber/VoIP client Jabbin which I requested sponsorship for earlier, however I am redoing the package from scratch and have decided that it is better to package snapshots from SVN rather than the not-exactly-stable releases. What is the preferred versioning scheme for SVN snapshots? On p.d.o I've seen various schemes, including things like 1:01.03.00.99.svn.300, 0.9.2+r1842.20061207 and 0.11.1+svn-r3965. Is it just a matter of personal preference? I guess it depends. If there has been no stable release with a version number, then something like 20070112svn is what I would use for the upstream version. Personally, I would stay away from using rev numbers since they are meaningless to anyone not intimately familiar with development of that package. For something that has had stable releases and you are packaging snapshots between releases, I would do something 1.1.15~20070112svn for the upstream version. Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: SVN snapshot versioning
Hi! On 1/22/07, Roberto C. Sanchez [EMAIL PROTECTED] wrote: I guess it depends. If there has been no stable release with a version number, then something like 20070112svn is what I would use for I would suggest using 0.0.date [1] snapshots between releases, I would do something 1.1.15~20070112svn for And I would suggest to use the revision number instead the date. :-) For example, there could be a lot of commits on the same day (and using just the date it's not possible to know exactly when the code was obtained from SVN.). It's better to use versions like 1:01.03.00.99.svn.300 and 0.11.1+svn-r3965 (my opinion). But there isn't a strict rule saying the package version MUST be like this. [1] http://www.us.debian.org/doc/maint-guide/ch-first.en.html#s-namever Best regards, Nelson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SVN snapshot versioning
On 1/23/07, Roberto C. Sanchez [EMAIL PROTECTED] wrote: I guess it depends. If there has been no stable release with a version number, then something like 20070112svn is what I would use for the upstream version. Personally, I would stay away from using rev numbers since they are meaningless to anyone not intimately familiar with development of that package. IMO revision numbers are more useful as they are easier to line up with upstream and if reporting a bug a revision number is probably more useful to the upstream developer, especially if more than one commit was made on one day. JFTR the software I am packaging has had semi-stable releases but they are few and far between and all bugfixing goes on in SVN. For something that has had stable releases and you are packaging snapshots between releases, I would do something 1.1.15~20070112svn for the upstream version. So for a snapshot of revision 91 between stable version 2.0 and future version 2.1, would something like: 2.1~20070123svn.r91 be OK? -- Andrew Donnellan ajdlinuxATgmailDOTcom (primary)ajdlinuxATexemailDOTcomDOTau (secure) http://andrewdonnellan.com http://ajdlinux.wordpress.com [EMAIL PROTECTED] hkp://subkeys.pgp.net 0x5D4C0C58 http://linux.org.auhttp://debian.org Get free rewards - http://ezyrewards.com/?id=23484 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SVN snapshot versioning
On Mon, Jan 22, 2007 at 10:14:50PM -0200, Nelson A. de Oliveira wrote: Hi! On 1/22/07, Roberto C. Sanchez [EMAIL PROTECTED] wrote: I guess it depends. If there has been no stable release with a version number, then something like 20070112svn is what I would use for I would suggest using 0.0.date [1] Good point. I forgot about this one. Regards, Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: SVN snapshot versioning
On 1/23/07, Andrew Donnellan [EMAIL PROTECTED] wrote: So for a snapshot of revision 91 between stable version 2.0 and future version 2.1, would something like: 2.1~20070123svn.r91 be OK? Another question: is it considered OK to leave .svn directories in the orig.tar.gz when packaging snapshots? -- Andrew Donnellan ajdlinuxATgmailDOTcom (primary)ajdlinuxATexemailDOTcomDOTau (secure) http://andrewdonnellan.com http://ajdlinux.wordpress.com [EMAIL PROTECTED] hkp://subkeys.pgp.net 0x5D4C0C58 http://linux.org.auhttp://debian.org Get free rewards - http://ezyrewards.com/?id=23484 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SVN snapshot versioning
On Tue, Jan 23, 2007 at 11:15:06AM +1100, Andrew Donnellan wrote: So for a snapshot of revision 91 between stable version 2.0 and future version 2.1, would something like: 2.1~20070123svn.r91 be OK? I like that. It is a sort of the best of both worlds approach. Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: SVN snapshot versioning
On Tue, Jan 23, 2007 at 11:17:53AM +1100, Andrew Donnellan wrote: Another question: is it considered OK to leave .svn directories in the orig.tar.gz when packaging snapshots? Lintian should flag this as an error or a warning. In short, no. You want to export and not simply checkout or packup a working directory. Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: SVN snapshot versioning
On 1/23/07, Roberto C. Sanchez [EMAIL PROTECTED] wrote: On Tue, Jan 23, 2007 at 11:17:53AM +1100, Andrew Donnellan wrote: Another question: is it considered OK to leave .svn directories in the orig.tar.gz when packaging snapshots? Lintian should flag this as an error or a warning. In short, no. You want to export and not simply checkout or packup a working directory. Thanks, I'm working on the package now and will probably send an RFS soon. -- Andrew Donnellan ajdlinuxATgmailDOTcom (primary)ajdlinuxATexemailDOTcomDOTau (secure) http://andrewdonnellan.com http://ajdlinux.wordpress.com [EMAIL PROTECTED] hkp://subkeys.pgp.net 0x5D4C0C58 http://linux.org.auhttp://debian.org Get free rewards - http://ezyrewards.com/?id=23484 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SVN snapshot versioning
also sprach Andrew Donnellan [EMAIL PROTECTED] [2007.01.23.0115 +0100]: So for a snapshot of revision 91 between stable version 2.0 and future version 2.1, would something like: 2.1~20070123svn.r91 Why bother with the date? 2.1~svn-r91 seems much more concise and has the same information, really. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems no, 'eureka' is greek for 'this bath is too hot.' -- dr. who signature.asc Description: Digital signature (GPG/PGP)
Re: SVN snapshot versioning
On Tue, Jan 23, 2007 at 01:39:30AM +0100, martin f krafft wrote: also sprach Andrew Donnellan [EMAIL PROTECTED] [2007.01.23.0115 +0100]: So for a snapshot of revision 91 between stable version 2.0 and future version 2.1, would something like: 2.1~20070123svn.r91 Why bother with the date? 2.1~svn-r91 seems much more concise and has the same information, really. I disagree. How do I know that r91 was committed two days ago? I think that having the date in the version gives the end user a good idea of the freshness of the program. Without it, the user would be required to look at the source control upstream to see when it was committed. Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: SVN snapshot versioning
On Tue, Jan 23, 2007 at 01:39:30AM +0100, martin f krafft wrote: also sprach Andrew Donnellan [EMAIL PROTECTED] [2007.01.23.0115 +0100]: So for a snapshot of revision 91 between stable version 2.0 and future version 2.1, would something like: 2.1~20070123svn.r91 Why bother with the date? 2.1~svn-r91 seems much more concise and has the same information, really. Sorry to have fogotten the specific rules around this, but would we ever run into sorting issues with the revision portion of the package version if we use only the revision number? i.e. is 2.1~svn-r91 2.1~svn-r115 ? Thanks, tony -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SVN snapshot versioning
On Mon, 22 Jan 2007, tmancill wrote: Sorry to have fogotten the specific rules around this, but would we ever run into sorting issues with the revision portion of the package version if we use only the revision number? i.e. is 2.1~svn-r91 2.1~svn-r115 ? No, but anytime you're unsure about this, you should check: $ dpkg --compare-versions 2.1~svn-r91 '' 2.1~svn-r115 echo 1 1 Don Armstrong -- Cheop's Law: Nothing ever gets built on schedule or within budget. -- Robert Heinlein _Time Enough For Love_ p242 http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SVN snapshot versioning
also sprach tmancill [EMAIL PROTECTED] [2007.01.23.0050 +]: Sorry to have fogotten the specific rules around this, but would we ever run into sorting issues with the revision portion of the package version if we use only the revision number? i.e. is 2.1~svn-r91 2.1~svn-r115 ? Good thinking, you got me there for a second. But it does not seem like this is a worry: lapse:~ dpkg --compare-versions 2.1~svn-r91 gt 2.1~svn-r115 || echo no no -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems all i know is that i'm being sued for unfair business practices by micro$oft. hello pot? it's kettle on line two. -- michael robertson signature.asc Description: Digital signature (GPG/PGP)
Re: SVN snapshot versioning
On Tue, Jan 23, 2007 at 01:26:09AM +, martin f krafft wrote: Good thinking, you got me there for a second. But it does not seem like this is a worry: lapse:~ dpkg --compare-versions 2.1~svn-r91 gt 2.1~svn-r115 || echo no no I thought would be more appropriate. Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
