5:47 a.m.
This package just numbers their tarballs using the subversion release
number. For example, 'r8' and 'r11':
http://code.google.com/p/dlfcn-win32/downloads/list
As far as I'm aware they are not planning on using "real" version
numbers at any time in the future, nor have they used real version
numbers in the past.
I don't understand which if any of these guidelines apply to this
case:
https://fedoraproject.org/wiki/Packaging/NamingGuidelines#NonNumericRelease
In particular, what should the Version be? (And while we're at it,
what should the Release be?)
Rich.
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v
6:45 a.m.
Richard W.M. Jones schrieb:
This package just numbers their tarballs using the subversion
release
number. For example, 'r8' and 'r11':
http://code.google.com/p/dlfcn-win32/downloads/list
As far as I'm aware they are not planning on using "real" version
numbers at any time in the future, nor have they used real version
numbers in the past.
I don't understand which if any of these guidelines apply to
this
case:
https://fedoraproject.org/wiki/Packaging/NamingGuidelines#NonNumericRelease
Not quite. These guidelines are referring to assuring consistency of common
upstream pre-release/alpha-/beta- (eg. 1.2.3pre1), upstream
post-release/bugfix
(e.g. 1.2.3fix1), VCS/date-versioning (e.g. 1.2.3-20081230) schemes with
"pure numerical" versioning schemes (e.g. 1.2.3).
In particular, what should the Version be? (And while we're at
it,
what should the Release be?)
rpm-wise, versions and releases are mere
"strings", with complex
comparision-operations attached to them.
I.e. there is no requirement to have mere numerical %version-%releases,
strings are allowed.
The only restriction is each package's NEVR to be steadily increasing
between different versions of a package, wrt. rpm's version comparision
operations.
I.e. if I understand your case correctly (upstream using r<N>), you
could directly use their version strings as %version and chose %release
at your personal preference.
Ralf
7:08 a.m.
New subject: Confused by non-numeric version in release guideline
Le Mar 13 janvier 2009 13:45, Ralf Corsepius a écrit :
I.e. if I understand your case correctly (upstream using r<N>),
you
could directly use their version strings as %version and chose
It's probably better to use just <N> in that case as alphanumeric
versions tend to bite you sooner or later
--
Nicolas Mailhot
7:21 a.m.
Nicolas Mailhot schrieb:
Le Mar 13 janvier 2009 13:45, Ralf Corsepius a écrit :
> I.e. if I understand your case correctly (upstream using r<N>), you
> could directly use their version strings as %version and chose
It's probably better to use just <N> in that case as alphanumeric
versions tend to bite you sooner or later
They don't bite you much more than using numerical versions do
or using proprietary handcrafted versions which are diverging
from upstream.
Ralf
10:53 a.m.
Richard W.M. Jones wrote:
This package just numbers their tarballs using the subversion
release
number. For example, 'r8' and 'r11':
http://code.google.com/p/dlfcn-win32/downloads/list
As far as I'm aware they are not planning on using "real" version
numbers at any time in the future, nor have they used real version
numbers in the past.
Note that the crux of this statement is "at any time in the future".
If
upstream dies and then is revitalized later and the new project lead
starts releasing tarballs, you could need epoch to get out of the
versioning scheme you choose. (However, epoch does exist, so it's not
like you can't escape).
I don't understand which if any of these guidelines apply to
this
case:
https://fedoraproject.org/wiki/Packaging/NamingGuidelines#NonNumericRelease
In particular, what should the Version be? (And while we're at it,
what should the Release be?)
In my personal descending order of preference I would do one of these:
Version: 0
Release: 1.rNNN
Version: 0
Release: 1.DATEsvnNNN
Version: NNNN
Release: 1
Version: rNNNN
Release: 1
The first, second, and fourth are reasonably safe in case a new upstream
emerges at some point in the future and decides to make releases with
version numbers. The third would need an epoch if that were to occur.
The first and second will survive if upstream switches to a new version
control system which doesn't have release numbers (for instance, git and
starts using dates) or has different release numbers (ie, starting over
from 1) while the other two could require changes.
The first and second most closely follow the letter of our guidelines
(non-numeric version and snapshot package respectively) so they will be
least confusing if you get a reviewer who thinks that's important and
also will help any packager who takes over from you not make silly
mistakes if they don't understand the limitations of the other forms.
The first doesn't make you figure out the date which is irrelevant since
you're pulling from a released tarball.
The fourth, while closest to what upstream has, includes an alpha
character in the version which is something that is explicitly forbidden
in the Packaging Guidelines. If you want to use that, we'll need to
vote on an amendment to allow it.
-Toshio
11:23 a.m.
Toshio Kuratomi <a.badger(a)gmail.com> writes:
The fourth, while closest to what upstream has, includes an alpha
character in the version which is something that is explicitly forbidden
in the Packaging Guidelines. If you want to use that, we'll need to
vote on an amendment to allow it.
Really? Don't expect me to adhere to that guideline when packaging
something whose upstream uses a letter in the version number.
regards, tom lane
11:33 a.m.
>>>> "TL" == Tom Lane <tgl(a)redhat.com>
writes:
TL> Really? Don't expect me to adhere to that guideline when
TL> packaging something whose upstream uses a letter in the version
TL> number.
Really? Don't expect me to adhere to any guideline that I ever happen
to disagree with at any point in time, ever. Rules simply don't apply
to me, regardless of how well-considered they are.
There, fixed it for you.
- J<
11:34 a.m.
Tom Lane wrote:
Toshio Kuratomi <a.badger(a)gmail.com> writes:
> The fourth, while closest to what upstream has, includes an alpha
> character in the version which is something that is explicitly forbidden
> in the Packaging Guidelines. If you want to use that, we'll need to
> vote on an amendment to allow it.
Really? Don't expect me to adhere to that guideline when packaging
something whose upstream uses a letter in the version number.
Instead of complaining, get it fixed.
1) Figure out what upstream version number has a problem.
2) Write a draft to change the guideline with the justification
3) Put it under PackagingDrafts and list it on the PackagingDrafts/ page.
Alternatively to #2, use your justification to convince someone else to
do steps 2+ for you.
-Toshio
12:52 p.m.
Toshio Kuratomi <a.badger(a)gmail.com> writes:
Tom Lane wrote:
> Really? Don't expect me to adhere to that guideline when packaging
> something whose upstream uses a letter in the version number.
>
Instead of complaining, get it fixed.
1) Figure out what upstream version number has a problem.
Well, I don't have to look very far: among my own packages I find
/home/tgl/f-pkg/libjpeg/devel/libjpeg.spec:Version: 6b
It cannot possibly be a good idea to use something other than the
upstream version number in Version --- the ensuing confusion would
trump whatever rationale there might be for this guideline.
While I hope that there will soon be a new libjpeg upstream release
that uses a more typical m.n type of number, it's folly to imagine that
Fedora can dictate upstream version numbering practices.
regards, tom lane
12:57 p.m.
On Tue, 2009-01-13 at 13:52 -0500, Tom Lane wrote:
Toshio Kuratomi <a.badger(a)gmail.com> writes:
> Tom Lane wrote:
>> Really? Don't expect me to adhere to that guideline when packaging
>> something whose upstream uses a letter in the version number.
>>
> Instead of complaining, get it fixed.
> 1) Figure out what upstream version number has a problem.
Well, I don't have to look very far: among my own packages I find
/home/tgl/f-pkg/libjpeg/devel/libjpeg.spec:Version: 6b
It cannot possibly be a good idea to use something other than the
upstream version number in Version --- the ensuing confusion would
trump whatever rationale there might be for this guideline.
While I hope that there will soon be a new libjpeg upstream release
that uses a more typical m.n type of number, it's folly to imagine that
Fedora can dictate upstream version numbering practices.
No one said dictate. You ask to get it fixed, if possible. You cajole,
bribe, etc.
It's not like fedora is the only distro impacted by this.
-sv
1:16 p.m.
seth vidal <skvidal(a)fedoraproject.org> writes:
On Tue, 2009-01-13 at 13:52 -0500, Tom Lane wrote:
> It cannot possibly be a good idea to use something other than the
> upstream version number in Version --- the ensuing confusion would
> trump whatever rationale there might be for this guideline.
>
> While I hope that there will soon be a new libjpeg upstream release
> that uses a more typical m.n type of number, it's folly to imagine that
> Fedora can dictate upstream version numbering practices.
No one said dictate. You ask to get it fixed, if possible. You
cajole,
bribe, etc.
[ shrug... ] If the guideline said "non-numeric versions are bad;
if you have such a package, try to persuade upstream to use a saner
versioning scheme next time, and here are reasons x, y, and z to
persuade them with", I'd be fine with that. As it is, all I see is
an arbitrary exercise of power that will have the principal result
of confusing users.
The very fine fine print of
https://fedoraproject.org/wiki/Packaging/NamingGuidelines#NonNumericRelease
appears to allow "6b" as a version number under the guise of
"post-release packages", so we don't need to have a war about libjpeg in
particular. But the whole thing reads to me like an exercise in wishful
thinking. It's describing somebody's idea of what version numbering
ought to be like, not what upstreams actually use in practice.
regards, tom lane
1:28 p.m.
Le mardi 13 janvier 2009 à 14:16 -0500, Tom Lane a écrit :
The very fine fine print of
https://fedoraproject.org/wiki/Packaging/NamingGuidelines#NonNumericRelease
appears to allow "6b" as a version number under the guise of
"post-release packages", so we don't need to have a war about libjpeg in
particular. But the whole thing reads to me like an exercise in wishful
thinking. It's describing somebody's idea of what version numbering
ought to be like, not what upstreams actually use in practice.
It's describing version numbering that people undestand and that will
work in rpm.
What's wishful thinking is to think you can drop just any versionning
convention in rpm and it will magically process it.
Before this convention was written we had many cases of packagers with
the same attitude as you that blindly dropped upstream versions in rpm
and where surprised when they upgrade paths didn't work. You can see the
traces to this day in packages with insane epoch numbers used to
workaround broken versionning.
--
Nicolas Mailhot
2:33 p.m.
Nicolas Mailhot <nicolas.mailhot(a)laposte.net> writes:
Le mardi 13 janvier 2009 à 14:16 -0500, Tom Lane a écrit :
> ... But the whole thing reads to me like an exercise in wishful
> thinking. It's describing somebody's idea of what version numbering
> ought to be like, not what upstreams actually use in practice.
It's describing version numbering that people undestand and that
will
work in rpm.
What's wishful thinking is to think you can drop just any
versionning
convention in rpm and it will magically process it.
No, the wishful thinking is that the Fedora guidelines can issue an
edict sans justification and expect that upstreams will start following
it. The entire text of this guideline should be replaced by "Try to get
your upstream to use a versioning convention that rpm understands", plus
a link to some reliable documentation about what it understands.
regards, tom lane
3:24 p.m.
Rex Dieter wrote:
That's a general problem, where to draw the line in including
explanations or justifications for said guidelines.
As one who learns best when an
issue is understood, rather than just
rote learned, I would be all for allowing the guidelines to include
discrete "more info" type of links into the wiki. The target page might
directly describe the issue/thinking etc, or provide links to the
discussion that lead to the guideline, or to other documentation eg rpm
manual.
DaveT.
3 p.m.
>>>> "TL" == Tom Lane <tgl(a)redhat.com>
writes:
TL> No, the wishful thinking is that the Fedora guidelines can issue
TL> an edict sans justification and expect that upstreams will start
TL> following it.
We don't expect upstreams to follow Fedora guidelines. We expect
Fedora packagers to follow Fedora guidelines. If you can get
upstreams to make things easier on you, so much the better.
Otherwise, adapt.
- J<
2:16 p.m.
Tom Lane wrote:
But the whole thing reads to me like an exercise in wishful
thinking. It's describing somebody's idea of what version numbering
ought to be like, not what upstreams actually use in practice.
Your other argument that there can be confusion when using something
that is not upstream's version number has validity to it but this does
not. There's no attempt by the Guidelines to change upstream's
versioning practices, only how to accommodate their versioning practices
within the realm of what rpm can handle.
So if you still care, please draft a Guideline change. I'd probably use
the user confusion argument as primary justification and propose that
epoch be used when versioning problems crop up. Note that much of the
information on the page would need to be rewritten to show when epoch
should be used if this is the proposal.
-Toshio
12:07 p.m.
Toshio Kuratomi schrieb:
Richard W.M. Jones wrote:
> This package just numbers their tarballs using the subversion release
> number. For example, 'r8' and 'r11':
>
> http://code.google.com/p/dlfcn-win32/downloads/list
>
> As far as I'm aware they are not planning on using "real" version
> numbers at any time in the future, nor have they used real version
> numbers in the past.
>
Note that the crux of this statement is "at any time in the future". If
upstream dies and then is revitalized later and the new project lead
starts releasing tarballs, you could need epoch to get out of the
versioning scheme you choose. (However, epoch does exist, so it's not
like you can't escape).
> I don't understand which if any of these guidelines apply to this
> case:
>
> https://fedoraproject.org/wiki/Packaging/NamingGuidelines#NonNumericRelease
>
> In particular, what should the Version be? (And while we're at it,
> what should the Release be?)
>
In my personal descending order of preference I would do one of these:
Version: 0
Release: 1.rNNN
Version: 0
Release: 1.DATEsvnNNN
Version: NNNN
Release: 1
Version: rNNNN
Release: 1
Urgh, ... insane overengineering, IMNSHO.
All you are doing is adding confusion on user-expections on versions
strings and avoidable hassle to package maintainers.
Ralf
12:24 p.m.
On Tue, Jan 13, 2009 at 07:07:15PM +0100, Ralf Corsepius wrote:
Urgh, ... insane overengineering, IMNSHO.
All you are doing is adding confusion on user-expections on versions
strings and avoidable hassle to package maintainers.
It really depends on the case at hand. All of those alternatives have
issues (epoch versus not following upstream). Chosing the right one
would mean knowing the future, since this is not really easy, letting
the maintainer chose one of the possibilities, but in an informed way
is, in my opinion, the best.
--
Pat
4:14 p.m.
Patrice Dumas schrieb:
On Tue, Jan 13, 2009 at 07:07:15PM +0100, Ralf Corsepius wrote:
> Urgh, ... insane overengineering, IMNSHO.
>
> All you are doing is adding confusion on user-expections on versions
> strings and avoidable hassle to package maintainers.
It really depends on the case at hand. All of those alternatives have
issues (epoch versus not following upstream).
Not quite - All "upstream
version" -> "rpm EVR" schemes have issues
somewhere, no matter which scheme is favored.
Chosing the right one
would mean knowing the future,
There is no "everlasting right one", there
only are "temporary right ones"
since this is not really easy, letting
the maintainer chose one of the possibilities, but in an informed way
is, in my opinion, the best.
My view is different: A package's maintainer has
to find a reasonable
compromise between upstream, user-expectation, ease of maintenance and
technical possibilities - Choose bizarre version tags is not helpful to
anybody.
Or differently: If upstream chooses alpha-numeric versions, it would be
silly to use "integer versions" in Fedora.
Ralf
6 p.m.
On Tue, Jan 13, 2009 at 08:53:58AM -0800, Toshio Kuratomi wrote:
In my personal descending order of preference I would do one of
these:
Version: 0
Release: 1.rNNN
Thanks ..
For the moment I've used:
Version: 0.1
Release: 0.1.r11
Ignore the Version number for now - I can change that to just be '0'
later if necessary.
How about the Release number: Isn't it more correct to use 0.<n>.r<mm>
instead of <n>.r<mm>? (I mean, in case upstream decides to use 0 or
0.1 as a real version number later on?)
This is the package:
https://bugzilla.redhat.com/show_bug.cgi?id=478640
Rich.
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top
2:59 a.m.
Richard W.M. Jones wrote:
On Tue, Jan 13, 2009 at 08:53:58AM -0800, Toshio Kuratomi wrote:
> In my personal descending order of preference I would do one of these:
> Version: 0
> Release: 1.rNNN
Thanks ..
For the moment I've used:
Version: 0.1
Release: 0.1.r11
What issue are you trying to solve by this choice?
You are not solving anything.
How about the Release number: Isn't it more correct to use
0.<n>.r<mm>
instead of <n>.r<mm>? (I mean, in case upstream decides to use 0 or
0.1 as a real version number later on?)
The release numbers don't really
matter. Much about them is personal
preference and personal use-case.
This is the package:
https://bugzilla.redhat.com/show_bug.cgi?id=478640
I would reject it due to your
choice of version.
Ralf
3:01 a.m.
On Wed, Jan 14, 2009 at 09:59:52AM +0100, Ralf Corsepius wrote:
Richard W.M. Jones wrote:
> On Tue, Jan 13, 2009 at 08:53:58AM -0800, Toshio Kuratomi wrote:
>> In my personal descending order of preference I would do one of these:
>> Version: 0
>> Release: 1.rNNN
>
> Thanks ..
>
> For the moment I've used:
>
> Version: 0.1
> Release: 0.1.r11
What issue are you trying to solve by this choice?
You are not solving anything.
I don't understand what you mean.
Rich.
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v
3:15 a.m.
Richard W.M. Jones wrote:
On Wed, Jan 14, 2009 at 09:59:52AM +0100, Ralf Corsepius wrote:
> Richard W.M. Jones wrote:
>> On Tue, Jan 13, 2009 at 08:53:58AM -0800, Toshio Kuratomi wrote:
>>> In my personal descending order of preference I would do one of these:
>>> Version: 0
>>> Release: 1.rNNN
>> Thanks ..
>>
>> For the moment I've used:
>>
>> Version: 0.1
>> Release: 0.1.r11
> What issue are you trying to solve by this choice?
>
> You are not solving anything.
I don't understand what you mean.
Let me turn my question around: Why can't you directly use the upstream
version?
Ralf
3:31 a.m.
On Wed, Jan 14, 2009 at 10:15:12AM +0100, Ralf Corsepius wrote:
Richard W.M. Jones wrote:
> On Wed, Jan 14, 2009 at 09:59:52AM +0100, Ralf Corsepius wrote:
>> Richard W.M. Jones wrote:
>>> On Tue, Jan 13, 2009 at 08:53:58AM -0800, Toshio Kuratomi wrote:
>>>> In my personal descending order of preference I would do one of these:
>>>> Version: 0
>>>> Release: 1.rNNN
>>> Thanks ..
>>>
>>> For the moment I've used:
>>>
>>> Version: 0.1
>>> Release: 0.1.r11
>> What issue are you trying to solve by this choice?
>>
>> You are not solving anything.
>
> I don't understand what you mean.
Let me turn my question around: Why can't you directly use the upstream
version?
I'm just trying to work out the best way to do this. Can you not ask
cryptic rhetorical questions and just say why the version and release
scheme above, derived from Toshio's one, isn't right.
Rich.
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top
5:52 a.m.
Richard W.M. Jones wrote:
On Wed, Jan 14, 2009 at 10:15:12AM +0100, Ralf Corsepius wrote:
> Richard W.M. Jones wrote:
>> On Wed, Jan 14, 2009 at 09:59:52AM +0100, Ralf Corsepius wrote:
>>> Richard W.M. Jones wrote:
>>>> On Tue, Jan 13, 2009 at 08:53:58AM -0800, Toshio Kuratomi wrote:
>>>>> In my personal descending order of preference I would do one of
these:
>>>>> Version: 0
>>>>> Release: 1.rNNN
>>>> Thanks ..
>>>>
>>>> For the moment I've used:
>>>>
>>>> Version: 0.1
>>>> Release: 0.1.r11
>>> What issue are you trying to solve by this choice?
>>>
>>> You are not solving anything.
>> I don't understand what you mean.
> Let me turn my question around: Why can't you directly use the upstream
> version?
I'm just trying to work out the best way to do this. Can you not ask
cryptic rhetorical questions
These aren't rhetorical question.
My point are:
* There is nothing technically wrong with using this upstream's versioning.
* Their versioning fits well in to rpm's versioning.
=> There is no reason to introduce a diverge versioning for your packages.
and just say why the version and release
scheme above, derived from Toshio's one, isn't right.
It isn't
technically wrong, I simply consider his proposal to be
foolish, silly and stupid.
Ralf
9:18 a.m.
>>>> "RC" == Ralf Corsepius
<rc040203(a)freenet.de> writes:
RC> It isn't technically wrong, I simply consider his proposal to be
RC> foolish, silly and stupid.
Because being insulting is obviously the best way to constructively
criticize something.
Look, Ralf, you occasionally have good things to say. But when you
write things like the above, you're just not being useful, OK? It's
just unwanted noise.
- J<
11:07 a.m.
Jason L Tibbitts III wrote:
>>>>> "RC" == Ralf Corsepius
<rc040203(a)freenet.de> writes:
RC> It isn't technically wrong, I simply consider his proposal to be
RC> foolish, silly and stupid.
Because being insulting is obviously the best way to constructively
criticize something.
Look, Ralf, you occasionally have good things to say. But when you
write things like the above, you're just not being useful, OK?
It's just unwanted noise.
OK, I realize you don't want to be told what you
don't want to hear, no
matter how silly/stupid/dumb/simple-minded a proposal might be.
Would you have preferred me naming Toshio's proposal as "non-discuss
worthy attempt of over-engineering"?
Ralf
11:14 a.m.
>>>> "RC" == Ralf Corsepius
<rc040203(a)freenet.de> writes:
RC> OK, I realize you don't want to be told what you don't want to
RC> hear, no matter how silly/stupid/dumb/simple-minded a proposal
RC> might be.
That's rather comical; you have no idea what my stance on this issue
is, yet you choose to argue against me anyway. If you were able to
articulate your thoughts in a manner which befits adult discussion, you
might even find that I agree with you. Anything is possible, as long
as you're willing to actually participate in a manner which reflects
the dignity of the people you are debating with.
- J<
4:40 a.m.
Ralf Corsepius wrote:
Richard W.M. Jones wrote:
> On Wed, Jan 14, 2009 at 09:59:52AM +0100, Ralf Corsepius wrote:
>
>> Richard W.M. Jones wrote:
>>
>>> For the moment I've used:
>>>
>>> Version: 0.1
>>> Release: 0.1.r11
>>>
>> What issue are you trying to solve by this choice?
>>
>> You are not solving anything.
>>
> I don't understand what you mean.
>
Let me turn my question around: Why can't you directly use the upstream
version?
Prepending 0.0 before the SVN version would avoid the need for an epoch
should upstream decide later on to release numbered versions, even one
as low as 0.1. (Though it cannot cover all possible ways upstream might
use to number releases.)
--
Don't get mad, get interest.
Eduardo M KALINOWSKI
eduardo(a)kalinowski.com.br
http://move.to/hpkb
5:54 a.m.
Eduardo M KALINOWSKI wrote:
Ralf Corsepius wrote:
> Richard W.M. Jones wrote:
>
>> On Wed, Jan 14, 2009 at 09:59:52AM +0100, Ralf Corsepius wrote:
>>
>>> Richard W.M. Jones wrote:
>>>
>>>> For the moment I've used:
>>>>
>>>> Version: 0.1
>>>> Release: 0.1.r11
>>>>
>>> What issue are you trying to solve by this choice?
>>>
>>> You are not solving anything.
>>>
>> I don't understand what you mean.
>>
> Let me turn my question around: Why can't you directly use the upstream
> version?
>
Prepending 0.0 before the SVN version would avoid the need for an epoch
should upstream decide later on to release numbered versions, even one
as low as 0.1.
Correct in case of svn snapshot version.
But this doesn't apply here. This upstream releases releases but call
them "r<N>".
(Though it cannot cover all possible ways upstream might
use to number releases.)
Correct.
Ralf
4:57 a.m.
On Wed, Jan 14, 2009 at 12:00:47AM +0000, Richard W.M. Jones wrote:
On Tue, Jan 13, 2009 at 08:53:58AM -0800, Toshio Kuratomi wrote:
> In my personal descending order of preference I would do one of these:
> Version: 0
> Release: 1.rNNN
Thanks ..
For the moment I've used:
Version: 0.1
Release: 0.1.r11
Ignore the Version number for now - I can change that to just be '0'
later if necessary.
Looks good to me. If version is set to 0, this is the safest choice
with regard to avoiding epochs in case upstream changes something
afterwards. This is also the numbering that is the most different from
upstream, but as long as you are aware of that...
--
Pat
5:55 a.m.
Patrice Dumas wrote:
On Wed, Jan 14, 2009 at 12:00:47AM +0000, Richard W.M. Jones wrote:
> On Tue, Jan 13, 2009 at 08:53:58AM -0800, Toshio Kuratomi wrote:
>> In my personal descending order of preference I would do one of these:
>> Version: 0
>> Release: 1.rNNN
> Thanks ..
>
> For the moment I've used:
>
> Version: 0.1
> Release: 0.1.r11
>
> Ignore the Version number for now - I can change that to just be '0'
> later if necessary.
Looks good to me. If version is set to 0, this is the safest choice
with regard to avoiding epochs in case upstream changes something
afterwards. This is also the numbering that is the most different from
upstream, but as long as you are aware of that...
Rubbish.
People will expect:
Requires: xxxx > r11
not
Requires: xxxx > 0.1.r11
Ralf
5573
days inactive
5575
days old
packaging@lists.fedoraproject.org
32 comments
11 participants
participants (11)
-
Development discussions related to Fedora -
Eduardo M KALINOWSKI -
Jason L Tibbitts III -
Nicolas Mailhot -
Patrice Dumas -
Ralf Corsepius -
Rex Dieter -
Richard W.M. Jones -
Seth Vidal -
Tom Lane -
Toshio Kuratomi