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
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
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:
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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?
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.
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
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
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
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
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
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
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
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
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
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,
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,
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
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
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
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
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,
35 matches
Mail list logo
