12:59 a.m.
What should I use for the release number in a spec when upstream does
not have releases, and *only* has git hashes? It's not a prerelease
since it is not clear that there will ever be any official release.
Thanks,
Eric
1:04 a.m.
I wrote:
What should I use for the release number in a spec when upstream does
not have releases, and *only* has git hashes? It's not a prerelease
since it is not clear that there will ever be any official release.
I meant "version number", not "release number". I imagine that the
release number should still be 0.1.<yyyymmdd>git<hashprefix>. Or for
this case, should the date and git hash go into the version?
Thanks,
Eric
2:13 a.m.
On 10/04/2011 08:04 AM, Eric Smith wrote:
I wrote:
> What should I use for the release number in a spec when upstream does
> not have releases, and *only* has git hashes? It's not a prerelease
> since it is not clear that there will ever be any official release.
I meant "version number", not "release number".
OK, this makes a big difference.
If the project doesn't use an internal version number, I'd use "0" and
never increment it.
If the project has some internal version number (e.g. most autoconf
based project have one, even if they don't have a release tarball), I'd
use this one.
I imagine that the
release number should still be 0.1.<yyyymmdd>git<hashprefix>.
I'd use "0.<yyyymmdd>git<hash>.%{?dist}" or similar.
The only points that count are
- Do not introduce (inofficial) version numbers (Upstream is the only
authority to set them), because they may cause problems, should upstream
once start to use version numbers.
- Within a "version" all release tags must be steadily incrementable and
should provide sufficient human readable information to allow others to
verify the tarball.
Or for
this case, should the date and git hash go into the version?
I'd recommend doing so, because this helps verifying/regenerating the
tarball.
On a wider scope, I'd however question if such a project is mature and
stable enough and maintained well enough to be included into Fedora.
Many projects, which do not release tarballs in longer terms often prove
to be poorly upstream maintained and to be problematic when it comes to
inclusion into a distro (e.g. lack of stable APIs, SONAME etc).
Ralf
9:38 a.m.
On Tue, Oct 04, 2011 at 09:13:46AM +0200, Ralf Corsepius wrote:
On 10/04/2011 08:04 AM, Eric Smith wrote:
> I wrote:
>> What should I use for the release number in a spec when upstream does
>> not have releases, and *only* has git hashes? It's not a prerelease
>> since it is not clear that there will ever be any official release.
>
> I meant "version number", not "release number".
OK, this makes a big difference.
If the project doesn't use an internal version number, I'd use "0" and
never increment it.
If the project has some internal version number (e.g. most autoconf
based project have one, even if they don't have a release tarball), I'd
use this one.
+1
> I imagine that the
> release number should still be 0.1.<yyyymmdd>git<hashprefix>.
I'd use "0.<yyyymmdd>git<hash>.%{?dist}" or similar.
Just to clarify -- this release string goes hand-in-hand with using 0 as the
version string. We're assuming that upstream will never release a version
0 and therefore the post-release snapshot form is better than the
pre-release form.
The only points that count are
- Do not introduce (inofficial) version numbers (Upstream is the only
authority to set them), because they may cause problems, should upstream
once start to use version numbers.
- Within a "version" all release tags must be steadily incrementable and
should provide sufficient human readable information to allow others to
verify the tarball.
+1
> Or for
> this case, should the date and git hash go into the version?
I'd recommend doing so, because this helps verifying/regenerating the
tarball.
I think you read this wrong or missed a negative in your reply. For me,
I would *not* recommend putting the date and git hash into the version.
(The release, yes; version, no). The hash definitely should not go there
because it cannot be depended on to increment. The date should not go there
as you cannot tell if upstream will someday switch to an actual version
string (which will then need an Epoch to upgrade cleanly from the date).
-Toshio
10:58 a.m.
On 4.10.2011 16:38, Toshio Kuratomi wrote:
The date should not go there
as you cannot tell if upstream will someday switch to an actual version
string (which will then need an Epoch to upgrade cleanly from the date).
That's your opinion or actually some rule? Well, it depends on the
upstream circumstances, but if reasonable, I would think this is exactly
the situation where I would leave incrementing epoch number as an
available fallback and just go with dates as versions. Having software
foo-0-0.<something very long and complicated>.fc16
seems like something so ugly, that I wouldn't go there as a long term
solution.
Matěj
2:01 p.m.
On Tue, Oct 04, 2011 at 05:58:33PM +0200, Matej Cepl wrote:
On 4.10.2011 16:38, Toshio Kuratomi wrote:
> The date should not go there
> as you cannot tell if upstream will someday switch to an actual version
> string (which will then need an Epoch to upgrade cleanly from the date).
That's your opinion or actually some rule? Well, it depends on the
upstream circumstances, but if reasonable, I would think this is exactly
the situation where I would leave incrementing epoch number as an
available fallback and just go with dates as versions. Having software
foo-0-0.<something very long and complicated>.fc16
seems like something so ugly, that I wouldn't go there as a long term
solution.
So my solyution:
foo-0-1.20110120git.fc16 vs
Your solution:
foo-20110120-1.20110120git.fc16
(Since it's a snapshot, the date has to go into the release string anyway)
Which is uglier?
Also, since these are snapshots, a date in the upstream version field isn't
really that great either. Which branch is this from? Which repository (in
the case of DVCS)? Now do we want to put the git hash into the version
field too?
If upstream is shipping releases where they put dates in as their versions
(as some fonts do) you might be able to make a case for this. In this case,
though, I don't think this is really a place to create our own release
string and put it in the field reserved for the upstream version.
-Toshio
11:32 p.m.
On 2011-10-04 12:01, Toshio Kuratomi wrote:
So my solyution:
foo-0-1.20110120git.fc16 vs
Your solution:
foo-20110120-1.20110120git.fc16
(Since it's a snapshot, the date has to go into the release string anyway)
Which is uglier?
Also, since these are snapshots, a date in the upstream version field isn't
really that great either. Which branch is this from? Which repository
(in the case of DVCS)?
With respect to a package's n-v-r, it doesn't matter which repository
one's checkout of a given git commit comes from. One of git's main
tenets is that a given hash refers to the same object in every
repository in which it exists. Git commit hashes are also independent
of the branches (if any) that point to them.
With respect to recording source URLs, we already require commentary
with a list of commands when people pull sources directly from version
control. This will necessarily include a URL for the appropriate git
repository.
Now do we want to put the git hash into the version field too?
For the package's n-v-r alone to uniquely refer to a given commit it
*must* contain the hash in a case such as this. To comply with
packaging guidelines it also needs to contain a date and the string
"git". This means it would need to contain 20111005git0123456.
(I would also posit that the date is unnecessary, as it may not identify
a unique commit, but that is a topic for another thread.)
If upstream is shipping releases where they put dates in as their
versions
(as some fonts do) you might be able to make a case for this. In this case,
though, I don't think this is really a place to create our own release
string and put it in the field reserved for the upstream version.
+1. I specifically suggest foo-0-1.20111005git0123456.fc16. Doing so
will do a number of useful things:
* A version of 0 is a clear signal that upstream does not use
traditional version numbering.
* A version of 0 provides a natural upgrade path if upstream later
chooses to start using traditional version numbering.
* Including the git hash makes the n-v-r alone refer to unique code.
* It does not duplicate information.
* It requires one to bend the fewest packaging guidelines. (One is only
filling the Version field with an obvious placeholder)
9:33 a.m.
On Tue, Oct 04, 2011 at 09:32:28PM -0700, Garrett Holmstrom wrote:
On 2011-10-04 12:01, Toshio Kuratomi wrote:
> So my solyution:
> foo-0-1.20110120git.fc16 vs
>
> Your solution:
> foo-20110120-1.20110120git.fc16
>
> (Since it's a snapshot, the date has to go into the release string anyway)
> Which is uglier?
>
> Also, since these are snapshots, a date in the upstream version field isn't
> really that great either. Which branch is this from? Which repository
> (in the case of DVCS)?
With respect to a package's n-v-r, it doesn't matter which repository
one's checkout of a given git commit comes from. One of git's main
tenets is that a given hash refers to the same object in every
repository in which it exists. Git commit hashes are also independent
of the branches (if any) that point to them.
With respect to recording source URLs, we already require commentary
with a list of commands when people pull sources directly from version
control. This will necessarily include a URL for the appropriate git
repository.
> Now do we want to put the git hash into the version field too?
For the package's n-v-r alone to uniquely refer to a given commit it
*must* contain the hash in a case such as this. To comply with
packaging guidelines it also needs to contain a date and the string
"git". This means it would need to contain 20111005git0123456.
To clarify what I meant since it seems both you and Ralf read this
differently than I intended:
I'm starting by saying that using date alone is not sufficient to identify
the checkout and therefore should not be used in the upstream Version:
field. I then put forward what I think people's next candidate would be:
the git hash. At that point, (I thought this but perhaps didn't write it
out) you run into the problem where the git hash does not increment and
therefore you potentially need to bump epoch with every release. So the git
hash is also not a good candidate for the upstream version field.
(I would also posit that the date is unnecessary, as it may not
identify
a unique commit, but that is a topic for another thread.)
The rationale is that the Release field is documenting for two audiences.
The important audience is the end user. The end user either doesn't know or
doesn't want to go through the trouble of verifying what version of software
a git hash refers to. They just want to be able to say that a bug was fixed
on January 1, 2011 or that Ubuntu has the 0.11 release from February 2,
2012 and then compare that to the Fedora package. The second audience is
other packagers and developers of the software. These people may want to
grab the exact snapshot of the software from upstream. If they don't want
to open up the spec file to see our comments on how to get the snapshot
(maybe they're actually Ubuntu devs and don't know how to get at that
information easily) the release field may optionally provide this
information.
-Toshio
11:53 p.m.
On 10/04/2011 09:01 PM, Toshio Kuratomi wrote:
On Tue, Oct 04, 2011 at 05:58:33PM +0200, Matej Cepl wrote:
> On 4.10.2011 16:38, Toshio Kuratomi wrote:
>> The date should not go there
>> as you cannot tell if upstream will someday switch to an actual version
>> string (which will then need an Epoch to upgrade cleanly from the date).
>
> That's your opinion or actually some rule?
It's common sense trying to
reflect the priniciple of "least conflict",
by avoiding potential NEVR conflicts with upstream and with 3rd party
package repos.
> Well, it depends on the
> upstream circumstances, but if reasonable, I would think this is exactly
> the situation where I would leave incrementing epoch number as an
> available fallback and just go with dates as versions. Having software
>
> foo-0-0.<something very long and complicated>.fc16
>
> seems like something so ugly, that I wouldn't go there as a long term
> solution.
>
So my solyution:
foo-0-1.20110120git.fc16 vs
Your solution:
foo-20110120-1.20110120git.fc16
(Since it's a snapshot, the date has to go into the release
string anyway)
Which is uglier?
IMO, without any doubt, the latter.
Also, since these are snapshots, a date in the upstream version field
isn't
really that great either. Which branch is this from?
Correct me if I'm wrong
(I am far from being a git specialist), but I
thought hashes were unique across branches?
Which repository (in
the case of DVCS)?
IMO, similar to tarballs, which are required to be provided by
the
project's master repository, sources pulled from git need to originate
from a project's public master repository.
Now do we want to put the git hash into the version
field too?
Yes, because "git checkouts by date" are not sufficiently
reliable to
provide deterministic checkouts from git.
Ralf
9:35 a.m.
On Wed, Oct 05, 2011 at 06:53:50AM +0200, Ralf Corsepius wrote:
On 10/04/2011 09:01 PM, Toshio Kuratomi wrote:
> Now do we want to put the git hash into the version
> field too?
Yes, because "git checkouts by date" are not sufficiently reliable to
provide deterministic checkouts from git.
I hope you don't really mean this. git hashes belong in the Release field;
not in the version field.
-Toshio
12:21 p.m.
On 10/05/2011 04:35 PM, Toshio Kuratomi wrote:
On Wed, Oct 05, 2011 at 06:53:50AM +0200, Ralf Corsepius wrote:
> On 10/04/2011 09:01 PM, Toshio Kuratomi wrote:
>
>> Now do we want to put the git hash into the version
>> field too?
> Yes, because "git checkouts by date" are not sufficiently reliable to
> provide deterministic checkouts from git.
>
I hope you don't really mean this.
Certainly not - "version <->
release" mixup on my part :() - Sorry.
git hashes belong in the Release field;
not in the version field.
I was advocating to mandate git hashes as part of the "release"-string,
because "checkouts by date" do not work well with git.
Ralf
4593
days inactive
4594
days old
10 comments
5 participants
participants (5)
-
Eric Smith -
Garrett Holmstrom -
Matej Cepl -
Ralf Corsepius -
Toshio Kuratomi