Hiyas,
the naming guidelines say that one should use the date do describe the snapshot:
http://fedoraproject.org/wiki/Packaging/NamingGuidelines#head-cfd71146dbb6f0...
| If a snapshot package is considered a "pre-release package", you should | follow the guidelines listed in Pre-Release Packages, and use an %{alphatag} | in the following format: | YYYYMMDDcvs
Maybe this is useful for cvs, because there is no better way to describe a snapshot. But e.g. with svn, which uses a global revision number, it is possible to use a unique id for the snapshot, where it is not uncertain which changes are included. For this reason I suggest to change the guideline, so that it suggests better identification strings for a snapshot, when it is avaiable, e.g.
123svn
for a snapshot of an svn repository at revision 123.
Regards, Till
"TM" == Till Maas opensource@till.name writes:
TM> For this reason I suggest to change the guideline, so that it TM> suggests better identification strings for a snapshot, when it is TM> avaiable, e.g.
TM> 123svn
TM> for a snapshot of an svn repository at revision 123.
The date must still be in there. Some packages have used a format like 20070412svn1234, which is acceptable although not strictly listed in the naming guidelines as one of the possibilities. (Which is something that probably should be in the guidelines.)
- J<
On Thursday 12 April 2007 17:38:58 Jason L Tibbitts III wrote:
The date must still be in there. Some packages have used a format like 20070412svn1234, which is acceptable although not strictly listed in the naming guidelines as one of the possibilities. (Which is something that probably should be in the guidelines.)
Well, since we have a 0.X.<snapshot> scheme, and X is always increasing, does it really matter if a date is in there, or that the numbers past X even increment the right way?
0.1.1234svn 0.2.1233svn 0.3.1334svn
Wouldn't those work? I think the only thing we'd want to avoid is the gnarly git and hg sha sums as revisions.
Jesse Keating wrote:
On Thursday 12 April 2007 17:38:58 Jason L Tibbitts III wrote:
The date must still be in there. Some packages have used a format like 20070412svn1234, which is acceptable although not strictly listed in the naming guidelines as one of the possibilities. (Which is something that probably should be in the guidelines.)
Well, since we have a 0.X.<snapshot> scheme, and X is always increasing, does it really matter if a date is in there, or that the numbers past X even increment the right way?
0.1.1234svn 0.2.1233svn 0.3.1334svn
Wouldn't those work?
imo, yes. As you(Jessie) pointed out, as long as the X in 0.X increments, I don't really care what comes after it (within reason and sanity, of course).
Unless there's some other reason for insisting on including the date, but I can't think of one atm.
-- Rex
Le jeudi 12 avril 2007 à 17:25 -0500, Rex Dieter a écrit :
Unless there's some other reason for insisting on including the date, but I can't think of one atm.
It's nice to see at a glance when looking at at a srpm if it's a recent or stale snapshot.
"JK" == Jesse Keating jkeating@redhat.com writes:
JK> Well, since we have a 0.X.<snapshot> scheme, and X is always JK> increasing, does it really matter if a date is in there, or that JK> the numbers past X even increment the right way?
Well, I've had this exact discussion at least twice before and it's always come down to precisely the scheme I indicated. Feel free to take my place for this trip through that discussion.
- J<
"JLT" == Jason L Tibbitts tibbs@math.uh.edu writes:
JLT> Well, I've had this exact discussion at least twice before and JLT> it's always come down to precisely the scheme I indicated.
Some bits from my IRC logs:
[Sat Aug 12 2006] [22:50:27] <tibbs> Hmmm, why do we mandate a date for the alphatag of an SVN checkout when the tree revision number actually makes more sense? [Sun Aug 13 2006] [02:13:27] <abadger1999> tibbs: Michael Schwendt explained on the list at one point that the date is portable in case upstream migrates to a different revision control system whereas the revision number is only applicable as long as they keep using subversion. A proposal was made to use DATEsvnREV# if you wanted to include the rev# information and some people have used that (but I don't think it made it into the official guidelines.) [Sun Aug 13 2006] [09:13:14] <tibbs> abadger1999: I think that's rather pointless given that you'd just bump the number that comes before the alphatag. [Sun Aug 13 2006] [09:13:57] <tibbs> It's like arguing that they could switch from SVN to CVS one day, and worrying about the version going backwards because CVS < SVN. [Sun Aug 13 2006] [10:02:07] <f13> are svn revisions rpmsortable ? [Sun Aug 13 2006] [10:08:27] <tibbs> Do they need to be? [Sun Aug 13 2006] [10:08:56] <tibbs> You're supposed to bump the number before the alphatag anyway. So sortability of the alphatag shouldn't make a difference. [Sun Aug 13 2006] [10:09:33] <tibbs> In any case, they're a monotonically increasing integer. I don't know if that's rpmsortable. [Sun Aug 13 2006] [10:30:31] <f13> if they increase thats fine [Sun Aug 13 2006] [10:30:47] <f13> as long as it isn't something with checksums (mercerial) [Sun Aug 13 2006] [10:41:34] <tibbs> Even then I don't see the problem. It's a string which (supposedly) uniquely identifies the checkout. [Sun Aug 13 2006] [10:41:47] <tibbs> The number before the alphatag is what imposes the ordering. [Sun Aug 13 2006] [10:42:15] <tibbs> Using dates is ambiguous in any case; CVS just doesn't provide anything better unless you tag every commit. [Sun Aug 13 2006] [10:42:45] <tibbs> I don't see why something better couldn't be used for version control systems which provide it (which is pretty much everything except CVS). [Sun Aug 13 2006] [10:51:22] <f13> tibbs: think of cases were nothing changes but the snapshot number [Sun Aug 13 2006] [11:00:58] <tibbs> So you bump the number before the alphatag. I don't see the problem. [Sun Aug 13 2006] [11:01:39] <tibbs> The naming guidelines say that you have to do that every time the snapshot number changes. [Sun Aug 13 2006] [11:05:15] <f13> do they? [Sun Aug 13 2006] [11:05:32] <tibbs> I'm looking at the kismet example: [Sun Aug 13 2006] [11:05:34] <tibbs> kismet-1.0-4.20050515cvs (bugfix to the post-release cvs checkout) [Sun Aug 13 2006] [11:05:39] <tibbs> kismet-1.0-5.20050517cvs (new cvs checkout, note the increment of %{X}) [Sun Aug 13 2006] [11:05:48] <tibbs> Looks like an increment just because the snapshot changed. [Sun Aug 13 2006] [11:06:19] <f13> looks like they do yeah. [Sun Aug 13 2006] [11:06:23] <tibbs> The examples seem consistent in that. [Sun Aug 13 2006] [11:06:35] <f13> nod [Sun Aug 13 2006] [11:06:47] <tibbs> It looks like everything expects that the alphatag does not impose a strict ordering. [Sun Aug 13 2006] [11:06:58] <f13> I don't have really any objections, it'll just get fun if we special case each and every SCM possibility [Sun Aug 13 2006] [11:10:33] <tibbs> I'm not sure we'd need to. [Sun Aug 13 2006] [11:11:18] <tibbs> If the SCM in use provides an identifier which uniquely specifies a particular checkout, then use it. There should still be room for common sense. [Sun Aug 13 2006] [11:11:59] <tibbs> The real problem is that dates don't uniquely identify checkouts. [Sun Aug 13 2006] [11:12:52] <tibbs> But of course in some cases using dates may just be simpler. SVN is kind of special, I think, because it's the only one that provides a monotonically increasing serial number. [Sun Aug 13 2006] [11:13:04] <f13> oh boy, I can't wait to see the first package that has a mercerial sha1sum in the release string. [Sun Aug 13 2006] [11:13:21] <tibbs> Well, a date would be completely useless there in any case. [Sun Aug 13 2006] [11:14:00] <f13> nod. [Sun Aug 13 2006] [11:14:14] <tibbs> Nothing we have allows specification of things like branches anyway. [Sun Aug 13 2006] [11:15:08] <tibbs> So perhaps the point isn't that the date tells you what to check out. [Sun Aug 13 2006] [11:15:31] <tibbs> (I wasn't around for the original discussion. I can't imagine that this kind of thing wasn't covered already.) [Sun Aug 13 2006] [11:15:34] <f13> nod, more of when the snapshot was taken. [Sun Aug 13 2006] [11:15:46] <f13> i wasn't around either. [Sun Aug 13 2006] [11:16:15] <tibbs> Perhaps it's best to leave additional data like that for comments in the spec file. [Sun Aug 13 2006] [11:17:30] <tibbs> What's confusing is that the name of the SCM gets put in the alphatag, which makes it look like the date somehow refers to some kind of SCM identifier. [Sun Aug 13 2006] [11:18:00] <f13> yeah, it was probably not really discussed regarding the other SCMs [Sun Aug 13 2006] [11:19:46] <tibbs> It's not as if a particular package is going to have more than one upstream SCM. [Sun Aug 13 2006] [11:20:34] <tibbs> So what's the point of even including it? Just to indicate that it was pulled from the SCM instead of from some released snapshot? [Sun Aug 13 2006] [11:26:27] <f13> not sure [Sun Aug 13 2006] [11:26:32] <f13> best would be to ask spot [Sun Aug 13 2006] [12:57:08] <abadger1999> tibbs: spot would be the only one to know all the reasoning behind the original naming. [Sun Aug 13 2006] [12:57:18] <abadger1999> Here's mschwendt's post: https://www.redhat.com/archives/fedora-extras-list/2006-January/msg00447.htm... [Sun Aug 13 2006] [12:58:58] <abadger1999> FWIW I agree that there's supposed to be an integer in the Release: before we get to this portion of the tag but you'll have to ask spot/mschwendt if there's something else going on.
- J<
On Thursday 12 April 2007 21:05:14 Jason L Tibbitts III wrote:
JLT> Well, I've had this exact discussion at least twice before and JLT> it's always come down to precisely the scheme I indicated.
Some bits from my IRC logs:
Seems we were in agreement with you here that something other than the date could be used.
I think Michael is just being difficult here. The date really doesn't help because on Today I could check out a tag from 4 years ago and make it a snapshot. No more meaning full than an svn revision number, in fact, LESS meaning full.
I'd fully support a draft to amend our guidelines around the snapshot stuff to be more flexible for things other than date.
On Fri, 2007-04-13 at 08:58 -0400, Jesse Keating wrote:
On Thursday 12 April 2007 21:05:14 Jason L Tibbitts III wrote:
JLT> Well, I've had this exact discussion at least twice before and JLT> it's always come down to precisely the scheme I indicated.
Some bits from my IRC logs:
Seems we were in agreement with you here that something other than the date could be used.
I agree.
I think Michael is just being difficult here. The date really doesn't help because on Today I could check out a tag from 4 years ago and make it a snapshot. No more meaning full than an svn revision number, in fact, LESS meaning full.
Well... only because our guidelines are poorly expressing the use of date. They assume that the snapshot is being taken on HEAD. A minor revision that makes date meaningful in this context would be "When using snapshots, use the date that can be used to checkout the tree you are using from the VCS."
I'd fully support a draft to amend our guidelines around the snapshot stuff to be more flexible for things other than date.
I would as well. Here are some things to consider:
Goals: * Ability to reproduce the snapshot by checking it out from the upstream VCS. - Note that the primary place that this should be documented is not in the release tag but in a comment in the spec file. * Ability for end users to tell how recent the snapshot is. * Ability for end users to compare the version they have against other available versions.
To me, the release tag after the rpmsortable integer is mostly for the end-user's benefit. So the latter two goals have more weight for me than the first.
Issues and Non-Issues: * The tag does not need to be rpmsortable as there should be an integer in the release tag that takes precedence over this. * Each VCS has different ids. (Note, I'm ignoring tags as that's not something we can control for making snapshots of upstream projects.) - cvs only has dates for whole-tree checkouts. - svn has dates and revision numbers - git has hashes and dates and ?? - hg has revision numbers, (hash|revision id)(Not sure which) and dates and ?? - bzr has revision numbers, revision ids, and dates. * Distributed VCS's start to take us into realms in addition to naming. For instance, upstream may have a canonical stable branch/repo and a canonical development branch/repo. A snapshot taken from either branch could be represented by the same date or revision number (ie: they are meaningless without also specifying the branch/repo they come from). They would have different revids/hashes.
Thoughts: Hashes and revisionids don't give very good information to the end user. Which is a newer snapshot: fa554dc or 65aad91?
Revision numbers (a monotonically incrementing number) and dates seem to have about the same benefits and drawbacks to me.
Dates are nice when used with HEAD checkouts because they tell the end user when an snapshot was taken at a glance. The packager has to work harder to get this benefit with historical checkouts (Figure out which date they want to grab from).
Revision numbers and distributed VCS's could be slightly confusing to the end user as a revision number, although monotonically increasing on a particular branch, could go backwards if the package was rebased against a different tree but hopefully that wouldn't happen very often.
I wouldn't be opposed to seeing revision numbers and/or dates used but revisionids and hashes should be banned. The canonical method of getting the snapshot should always be included in the spec file. Maybe something like this for prereleases:
foo-1.0-0.2.20061005cvs bar-1.0-0.2.512svn baz-1.0-0.3.123bzr spam-1.0-0.3.171hg ham-1.0-0.4.20070121git
-Toshio
On Fri, 2007-04-13 at 13:58 -0700, Toshio Kuratomi wrote:
foo-1.0-0.2.20061005cvs bar-1.0-0.2.512svn baz-1.0-0.3.123bzr spam-1.0-0.3.171hg ham-1.0-0.4.20070121git
My thoughts on this are pretty simple:
All checkout packages are either pre or post:
Pre:
%{name}-%{version}-0.1.%{alphatag}
Post:
%{name}-%{version}-1.%{alphatag}
%{alphatag} contains either the revision integer or the date of the checkout, followed by the revision type id:
RCS ID Format ===== ==== ======== CVS cvs date Subversion svn revision int Bazaar bzr revision int Git git date Mercurial hg revision int
If the Revision Control System uses simple, integer revisions, use that. If not, use the date of checkout. Revisionids and hashes are not permitted.
~spot
On Fri, Apr 13, 2007 at 10:43:02PM -0500, Tom spot Callaway wrote:
On Fri, 2007-04-13 at 13:58 -0700, Toshio Kuratomi wrote:
foo-1.0-0.2.20061005cvs bar-1.0-0.2.512svn baz-1.0-0.3.123bzr spam-1.0-0.3.171hg ham-1.0-0.4.20070121git
%{alphatag} contains either the revision integer or the date of the checkout, followed by the revision type id:
The convention is reversed, e.g. people say cvs20061005 and svn512. This doesn't change any ordering logig, is easier to read (the suffixing style merges the vcs id with the actual build ids, prefixing brings a eye-natural separator), and starting with a non-integer saves the day from funny ordering bug like the following:
foo-1.0-0.2.20061005cvs
A trivial rebuild (like a braindead EPEL mass rebuild with a mass .1 forking):
foo-1.0-0.2.1.20061005cvs < foo-1.0-0.2.20061005cvs
So instead of introducing major.%{alphatag}.minor braindamage to deal with the latter, let's make it even mandatory to start %{alphatag} with an `alpha' and you're set. And we're also following common conventions in naming snapshots and cvs checkouts.
BTW this is the reason why disttags also have to always start with a letter. At the beginning of Fedora Core there were disttags examined like "0.7.3", "0.8.0", "0.9", "1", "2", but they would fail in the same way as the example above, so they would have to get "fc" prepended, and having RHL9 carrying a disttag of "fc0.9" looked a bit awkward, so it never made it.
On Saturday 14 April 2007 05:24:24 Axel Thimm wrote:
The convention is reversed, e.g. people say cvs20061005 and svn512. This doesn't change any ordering logig, is easier to read (the suffixing style merges the vcs id with the actual build ids, prefixing brings a eye-natural separator),
I wouldn't mind this method either, although I'm ignoring the flamebait in the rest of this mail. The above was enough.
On Do April 12 2007, Jason L Tibbitts III wrote:
The date must still be in there. Some packages have used a format like 20070412svn1234, which is acceptable although not strictly listed in the naming guidelines as one of the possibilities. (Which is something that probably should be in the guidelines.)
I have a question about the date, in the guidelines it is written: | The date in reference is the date that the checkout was taken.
So when I take a snapshot of revision 123 of a svn repository with the current revision 151 and the commit of revision 123 was a week ago, then the alphatag has to be:
20070413svn123?
Imho it would make more sence to use the date of the commit of the revision.
Also with respect to git/hg, it would make the checkout better identifiable when one would use:
20070413gitABCDEF
with ABCDEF beeing the last six (or any other number of) characters of the sha1 hash of the revision.
Regards, Till
On Friday 13 April 2007 03:28:54 Till Maas wrote:
I have a question about the date, in the guidelines it is written: | The date in reference is the date that the checkout was taken.
So when I take a snapshot of revision 123 of a svn repository with the current revision 151 and the commit of revision 123 was a week ago, then the alphatag has to be:
20070413svn123?
Imho it would make more sence to use the date of the commit of the revision.
Also with respect to git/hg, it would make the checkout better identifiable when one would use:
20070413gitABCDEF
with ABCDEF beeing the last six (or any other number of) characters of the sha1 hash of the revision.
But the date of the checkin to who's branch, or is it the date of the checkin to the local person's clone, or the date after the clone was merged into the master repo or... I really think that Date here is arbitrary and half thought out. See my other post regarding a draft.
On Fr April 13 2007, Jesse Keating wrote:
But the date of the checkin to who's branch, or is it the date of the checkin to the local person's clone, or the date after the clone was merged into the master repo or... I really think that Date here is arbitrary and half thought out. See my other post regarding a draft.
I suggest to use date when the revision became available at the url (location) that is described in the comment / script, which explains how to generate the snapshot tarball (See: http://fedoraproject.org/wiki/Packaging/SourceURL#head-615f6271efb394ab340a9...).
Regards, Till
On Friday 13 April 2007, Jesse Keating wrote:
But the date of the checkin to who's branch, or is it the date of the checkin to the local person's clone, or the date after the clone was merged into the master repo or...
The release tag is not the place to even try to embed that info into. We want the exact commands how the snapshot was generated properly documented anyway. http://fedoraproject.org/wiki/PackagingDrafts/SourceUrl
On Fri, 2007-04-13 at 09:28 +0200, Till Maas wrote:
On Do April 12 2007, Jason L Tibbitts III wrote:
The date must still be in there. Some packages have used a format like 20070412svn1234, which is acceptable although not strictly listed in the naming guidelines as one of the possibilities. (Which is something that probably should be in the guidelines.)
I have a question about the date, in the guidelines it is written: | The date in reference is the date that the checkout was taken.
So when I take a snapshot of revision 123 of a svn repository with the current revision 151 and the commit of revision 123 was a week ago, then the alphatag has to be:
20070413svn123?
Imho it would make more sence to use the date of the commit of the revision.
Also with respect to git/hg, it would make the checkout better identifiable when one would use:
20070413gitABCDEF
with ABCDEF beeing the last six (or any other number of) characters of the sha1 hash of the revision.
To be logical about date (I won't defend the use of date here, just if it is being used) you could checkout by date: svn co -r '{2007-04-13}'
and then you can check which revid svn has given it with svn info if you want to include the revid as part of the release tag.
Or we could amend the guidelines to say date of commit. The guidelines actually mean: date-which-I-can-tell-the-revision-control-system-so-I-can-get-the-same-checkout-you-did
which is date of checkout when you checkout HEAD.
-Toshio
On Fr April 13 2007, Toshio Kuratomi wrote:
To be logical about date (I won't defend the use of date here, just if it is being used) you could checkout by date: svn co -r '{2007-04-13}'
This only works for dates that have already passed. It seems to me, that
svn co -r '{2007-04-13}'
will include any changesets up to 2007-04-13 00:00 (don't know which timezone, I guess the servers one). So when I want to include a changeset that happend later on 2007-04-13, I have to use
svn co -r '{2007-04-14}'
which will include all changesets up to now, but when invoked a day latey, it may include also other changesets. This is a problem I encountered yesterday, because I needed a recent revision, which contains a security fix.
date-which-I-can-tell-the-revision-control-system-so-I-can-get-the-same-che ckout-you-did
which is date of checkout when you checkout HEAD.
When is this meant, than in case of svn the revision would be a better substitution, when the date is today.
Regards, Till
Hi,
On Thu, Apr 12, 2007 at 09:59:54PM +0200, Till Maas wrote:
| If a snapshot package is considered a "pre-release package", you should | follow the guidelines listed in Pre-Release Packages, and use an %{alphatag} | in the following format: | YYYYMMDDcvs
Maybe this is useful for cvs, because there is no better way to describe a snapshot. But e.g. with svn, which uses a global revision number, it is possible to use a unique id for the snapshot, where it is not uncertain which changes are included.
Well, you are correct, just keep two things in mind:
a) the guideline above is a "should" guideline, which means no enforcement. So any sensible scheme is OK with the guidelines.
b) The idea is to avoid packaging snapshots. Of course there are projects that never release and still have a very good codebase that is worth packaging. But instead of putting energy into how to deal with unreleased software, maybe it's better to invest in persuading or helping the upstream project to stamp off a release.
FWIW if you're going to package svn sheckout the more or less canonical "snapshot" tag is r<snvrevison>, e.g. prepend a lower "r" in front of the revision.
On Thu, Apr 19, 2007 at 02:16:29PM -0400, Fernando Nasser wrote:
Axel Thimm wrote:
FWIW if you're going to package svn sheckout the more or less canonical "snapshot" tag is r<snvrevison>, e.g. prepend a lower "r" in front of the revision.
And a capital D for dates?
Is that a serious question, or is there a simley missing? :)
If it's serious: I suspect everyone can identify that something matching 2006XXXX or 2007XXXX implies a date, and if not a capital D won't help either.
If the similey was missing: Yes a capital D would be fine, but you should use the proper locale, not everywhere does a date translate to something that actually starts with a "d", at least in Greek it starts with an eta. ;)
Axel Thimm wrote:
On Thu, Apr 19, 2007 at 02:16:29PM -0400, Fernando Nasser wrote:
Axel Thimm wrote:
FWIW if you're going to package svn sheckout the more or less canonical "snapshot" tag is r<snvrevison>, e.g. prepend a lower "r" in front of the revision.
And a capital D for dates?
Is that a serious question, or is there a simley missing? :)
Yes, I thought it was obvious :-)
If it's serious: I suspect everyone can identify that something matching 2006XXXX or 2007XXXX implies a date, and if not a capital D won't help either.
If the similey was missing: Yes a capital D would be fine, but you should use the proper locale, not everywhere does a date translate to something that actually starts with a "d", at least in Greek it starts with an eta. ;)
I always add comments before the Source0: telling how to obtain the sources if it cannot be done directly with a URL on the Source0: specification.
Cheers, Fernando
On Do April 19 2007, Axel Thimm wrote:
If it's serious: I suspect everyone can identify that something matching 2006XXXX or 2007XXXX implies a date, and if not a capital D won't help either.
I would prefer to use YYYY-MM-DD which is easier to read and an ISO conform afaik. Would this cause any problems with rpm?
Regards, Till
On Thu, 2007-04-19 at 21:35 +0200, Till Maas wrote:
On Do April 19 2007, Axel Thimm wrote:
If it's serious: I suspect everyone can identify that something matching 2006XXXX or 2007XXXX implies a date, and if not a capital D won't help either.
I would prefer to use YYYY-MM-DD which is easier to read and an ISO conform afaik. Would this cause any problems with rpm?
If not with rpm, there's a good chance it will cause problems for people's local scripts because of dash's being used as separators for name-version-release.
-Toshio
On Thursday 19 April 2007, Toshio Kuratomi wrote:
On Thu, 2007-04-19 at 21:35 +0200, Till Maas wrote:
On Do April 19 2007, Axel Thimm wrote:
If it's serious: I suspect everyone can identify that something matching 2006XXXX or 2007XXXX implies a date, and if not a capital D won't help either.
I would prefer to use YYYY-MM-DD which is easier to read and an ISO conform afaik. Would this cause any problems with rpm?
If not with rpm, there's a good chance it will cause problems for people's local scripts because of dash's being used as separators for name-version-release.
rpmbuild refuses to build a package with dashes in Version or Release.
Le jeudi 19 avril 2007 à 21:35 +0200, Till Maas a écrit :
On Do April 19 2007, Axel Thimm wrote:
If it's serious: I suspect everyone can identify that something matching 2006XXXX or 2007XXXX implies a date, and if not a capital D won't help either.
I would prefer to use YYYY-MM-DD which is easier to read and an ISO conform afaik. Would this cause any problems with rpm?
IIRC the condensed form is legit too, even if it's far less readable. Since - is the rpm separator using YYYY-MM-DD may cause problems. Though it would be worth some testing before assuming it won't work.
On Thu, Apr 19, 2007 at 09:35:20PM +0200, Till Maas wrote:
On Do April 19 2007, Axel Thimm wrote:
If it's serious: I suspect everyone can identify that something matching 2006XXXX or 2007XXXX implies a date, and if not a capital D won't help either.
I would prefer to use YYYY-MM-DD which is easier to read and an ISO conform afaik. Would this cause any problems with rpm?
You can't have any dashes in either epoch/version/release, so you wouldn't be able to have ISO dates in the rpm filename.
But since you're going to not match 1005 the tarball's name with the EVR of the package, you could do with the tarball's naming what you want (within reason).
You could even add a capital "D" or a greek eta in front of it. :)
packaging@lists.fedoraproject.org
-
Axel Thimm -
Fernando Nasser -
Jason L Tibbitts III -
Jesse Keating -
Nicolas Mailhot -
Rex Dieter -
Till Maas -
Tom Callaway -
Toshio Kuratomi -
Ville Skyttä