Re: release number when upstream *only* has git hashes?
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 pgpAjvBypxtOn.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: release number when upstream *only* has git hashes?
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 pgp8UNwWCOi2U.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: release number when upstream *only* has git hashes?
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: release number when upstream *only* has git hashes?
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.mmddgithashprefix. Or for this case, should the date and git hash go into the version? Thanks, Eric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: release number when upstream *only* has git hashes?
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.mmddgithashprefix.
I'd use 0.mmddgithash.%{?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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: release number when upstream *only* has git hashes?
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.mmddgithashprefix.
I'd use 0.mmddgithash.%{?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
pgpxxnoUYXxHC.pgp
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: release number when upstream *only* has git hashes?
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: release number when upstream *only* has git hashes?
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 pgpLg3PwERaYL.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: release number when upstream *only* has git hashes?
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) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: release number when upstream *only* has git hashes?
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
release number when upstream *only* has git hashes?
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
