versions / suffixes in experimental
Is there any convention for version numbers in experimental? E.g. when uploading to backports, we add a suffix like A.B.C~bpo70+1 so that the system can cleanly upgrade to version A.B.C when upgrading to the next stable release. I have a package, version 2.2.5-5 in unstable and testing I uploaded 2.2.5-6 and 2.2.5-7 to experimental. Should I have given them versions like 2.2.5-6~exp1 or something and then upload a proper 2.2.5-6 to unstable when I am happy with it? Or should my next upload to unstable by 2.2.5-8? Or do I just ignore the version numbers I uploaded to experimental and use 2.2.5-6 as the next version number for an unstable upload, even if it doesn't contain the same things as 2.2.5-6 in experimental? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5423c15e.1090...@pocock.pro
Re: versions / suffixes in experimental
On Thu, 25 Sep 2014 09:16:46 +0200 Daniel Pocock dan...@pocock.pro wrote: Is there any convention for version numbers in experimental? E.g. when uploading to backports, we add a suffix like A.B.C~bpo70+1 so that the system can cleanly upgrade to version A.B.C when upgrading to the next stable release. I have a package, version 2.2.5-5 in unstable and testing I uploaded 2.2.5-6 and 2.2.5-7 to experimental. Should I have given them versions like 2.2.5-6~exp1 or something and then upload a proper 2.2.5-6 to unstable when I am happy with it? Or should my next upload to unstable by 2.2.5-8? Or do I just ignore the version numbers I uploaded to experimental and use 2.2.5-6 as the next version number for an unstable upload, even if it doesn't contain the same things as 2.2.5-6 in experimental? 2.2.5-8 would seem typical practice. 2.2.5-6 will not work for a new upload to unstable - it already exists in the archive. -- Neil Williams = http://www.linux.codehelp.co.uk/ signature.asc Description: PGP signature
Re: versions / suffixes in experimental
On 2014-09-25 8:16, Daniel Pocock wrote: Or should my next upload to unstable by 2.2.5-8? Or do I just ignore the version numbers I uploaded to experimental and use 2.2.5-6 as the next version number for an unstable upload, even if it doesn't contain the same things as 2.2.5-6 in experimental? No. Under no circumstances should version numbers be reused. (There's some disagreement about cases such as reintroducing old packages that aren't even in oldstable any more, but a contemporaneous upload to multiple suites using the same version number is absolutely wrong.) Regards, Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/3653b875c93fd474b8b354b4c76f4...@mail.adsl.funky-badger.org
Re: versions / suffixes in experimental
Quoting Daniel Pocock (2014-09-25 09:16:46) Is there any convention for version numbers in experimental? There are multiple conventions. E.g. when uploading to backports, we add a suffix like A.B.C~bpo70+1 so that the system can cleanly upgrade to version A.B.C when upgrading to the next stable release. I have a package, version 2.2.5-5 in unstable and testing I uploaded 2.2.5-6 and 2.2.5-7 to experimental. Should I have given them versions like 2.2.5-6~exp1 or something and then upload a proper 2.2.5-6 to unstable when I am happy with it? Or should my next upload to unstable by 2.2.5-8? Or do I just ignore the version numbers I uploaded to experimental and use 2.2.5-6 as the next version number for an unstable upload, even if it doesn't contain the same things as 2.2.5-6 in experimental? Both approaches makes sense to me - depending on your reason for using experimental in the first place - and on your mood. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: versions / suffixes in experimental
On Thu, 25 Sep 2014 09:42:42 +0200 Jonas Smedegaard d...@jones.dk wrote: Quoting Daniel Pocock (2014-09-25 09:16:46) I have a package, version 2.2.5-5 in unstable and testing I uploaded 2.2.5-6 and 2.2.5-7 to experimental. Should I have given them versions like 2.2.5-6~exp1 or something and then upload a proper 2.2.5-6 to unstable when I am happy with it? Or should my next upload to unstable by 2.2.5-8? Or do I just ignore the version numbers I uploaded to experimental and use 2.2.5-6 as the next version number for an unstable upload, even if it doesn't contain the same things as 2.2.5-6 in experimental? Both approaches makes sense to me - depending on your reason for using experimental in the first place - and on your mood. Any approach which tries to use the same version in multiple suites at the same time does not make sense to the archive. The mood of the maintainer is rightly ignored by dak. -- Neil Williams = http://www.linux.codehelp.co.uk/ signature.asc Description: PGP signature
Re: versions / suffixes in experimental
On 25/09/14 10:00, Neil Williams wrote: On Thu, 25 Sep 2014 09:42:42 +0200 Jonas Smedegaard d...@jones.dk wrote: Quoting Daniel Pocock (2014-09-25 09:16:46) I have a package, version 2.2.5-5 in unstable and testing I uploaded 2.2.5-6 and 2.2.5-7 to experimental. Should I have given them versions like 2.2.5-6~exp1 or something and then upload a proper 2.2.5-6 to unstable when I am happy with it? Or should my next upload to unstable by 2.2.5-8? Or do I just ignore the version numbers I uploaded to experimental and use 2.2.5-6 as the next version number for an unstable upload, even if it doesn't contain the same things as 2.2.5-6 in experimental? Both approaches makes sense to me - depending on your reason for using experimental in the first place - and on your mood. Any approach which tries to use the same version in multiple suites at the same time does not make sense to the archive. The mood of the maintainer is rightly ignored by dak. Personally, I think the suffix would be useful for cases where the upload to experimental and unstable are both otherwise identical If I upload 2.2.5-8 to unstable, should it include the changelog entries for experimental too or that doesn't matter either way? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5423dd42.6060...@pocock.pro
Re: versions / suffixes in experimental
Le Thu, Sep 25, 2014 at 11:15:46AM +0200, Daniel Pocock a écrit : On 25/09/14 10:00, Neil Williams wrote: On Thu, 25 Sep 2014 09:42:42 +0200 Jonas Smedegaard d...@jones.dk wrote: Quoting Daniel Pocock (2014-09-25 09:16:46) I have a package, version 2.2.5-5 in unstable and testing I uploaded 2.2.5-6 and 2.2.5-7 to experimental. Should I have given them versions like 2.2.5-6~exp1 or something and then upload a proper 2.2.5-6 to unstable when I am happy with it? Or should my next upload to unstable by 2.2.5-8? Or do I just ignore the version numbers I uploaded to experimental and use 2.2.5-6 as the next version number for an unstable upload, even if it doesn't contain the same things as 2.2.5-6 in experimental? Both approaches makes sense to me - depending on your reason for using experimental in the first place - and on your mood. Any approach which tries to use the same version in multiple suites at the same time does not make sense to the archive. The mood of the maintainer is rightly ignored by dak. Personally, I think the suffix would be useful for cases where the upload to experimental and unstable are both otherwise identical If I upload 2.2.5-8 to unstable, should it include the changelog entries for experimental too or that doesn't matter either way? Hi Daniel, Recently, I have have used Experimental as dead-end branches, for instance: - foo_1.2-3 uploaded to Unstable. - foo_1.2-4~experimental1 uploaded to Experimental - foo_1.2-4 uploaded to Unstable with the changelog entry from version 1.2-4~experimental1 merged in the entry for version 1.2-4. I think that this is nicer than having a changelog entry for Unstable pointing at the changelog entry from the upload to Experimental: think for instance to the links to the change files in the package tracker. Have a nice day, -- Charles -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140925092716.ga11...@falafel.plessy.net
Re: versions / suffixes in experimental
On Thu, Sep 25, 2014 at 09:16:46AM +0200, Daniel Pocock wrote: Is there any convention for version numbers in experimental? No such convention exists TTBOMK. [...] I uploaded 2.2.5-6 and 2.2.5-7 to experimental. Should I have given them versions like 2.2.5-6~exp1 or something and then upload a proper 2.2.5-6 to unstable when I am happy with it? Or should my next upload to unstable by 2.2.5-8? Both are okay. Or do I just ignore the version numbers I uploaded to experimental and use 2.2.5-6 as the next version number for an unstable upload, even if it doesn't contain the same things as 2.2.5-6 in experimental? As others have pointed out, dak will refuse this. This is only natural, if you think about it; when you upload something to experimental and later upload it to unstable but with a version number that sorts before the experimental version number, people who've used the experimental version will be stuck with the version they have, which is wrong any way you look at it. In theory, it *should* be okay to migrate packages from experimental to unstable without re-uploading them in the same manner that packages are migrated from unstable to testing without re-upload. I don't know if dak supports this mode of operation, however. -- It is easy to love a country that is famous for chocolate and beer -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140925094824.gb7...@grep.be
Re: versions / suffixes in experimental
On Thu, 25 Sep 2014 11:15:46 +0200 Daniel Pocock dan...@pocock.pro wrote: If I upload 2.2.5-8 to unstable, should it include the changelog entries for experimental too or that doesn't matter either way? Depends if 2.2.5-8 includes all the changes made in experimental or whether experimental was just for an experiment which itself led to a dead-end. If the changes are included, the changes need to be described in the changelog. Every change made to a package goes into the changelog. Changes not included in the package don't go into the changelog. /me not sure why this needs to be said. -- Neil Williams = http://www.linux.codehelp.co.uk/ signature.asc Description: PGP signature
Re: versions / suffixes in experimental
On 25/09/14 08:16, Daniel Pocock wrote: Is there any convention for version numbers in experimental? E.g. when uploading to backports, we add a suffix like A.B.C~bpo70+1 so that the system can cleanly upgrade to version A.B.C when upgrading to the next stable release. I have a package, version 2.2.5-5 in unstable and testing Approach 1, which is (IMO) better when the changes you are making in experimental are truly experimental, like enabling features or patches whose medium-term future you're not sure about: 2.2.5-5+exp1, ... or -6~exp1, ... or whatever to experimental 2.2.5-6 to unstable Approach 2, which is (IMO) better when the changes you are making in experimental are the main line of development, and you're only not uploading to unstable because you're trying to avoid a freeze or getting tangled into a transition or something: 2.2.5-6, -7, ... to experimental 2.2.5-5+deb8u1 to unstable (if needed) (i.e. in approach 2 you're treating the unstable branch as stable-updates to a stable release that doesn't exist yet). Either can work. I've done both in the past. If the upstream versions in unstable and experimental are different (as in, for instance, GNOME a couple of weeks ago, with 3.12.x in unstable and 3.13.x in experimental), then you don't need a special suffix either way because the upstream versions are sufficient. S -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5423ebf0.2040...@debian.org
Re: versions / suffixes in experimental
On Thu, 25 Sep 2014, Simon McVittie wrote: Approach 1, which is (IMO) better when the changes you are making in experimental are truly experimental, like enabling features or patches whose medium-term future you're not sure about: 2.2.5-5+exp1, ... or -6~exp1, ... or whatever to experimental 2.2.5-6 to unstable Keep in mind the BTS version tracking requirements, which translate into requirements for which past package changelog entries must be included in debian/changelog as well. When there is a continuity in the bug-tracking sense between 2.2.5-5~exp1 and 2.2.5-6~exp1, regardless of what your workflow is, 2.2.5-6~exp1's debian/changelog must include a merge of 2.2.5-5~exp1's debian/changelog and 2.2.5-6's debian/changelog. Otherwise, as soon as 2.2.5-6~exp1 gets installed in experimental, the BTS will think any bugs against 2.2.5-5~exp1 are on a different branch, and will not consider these closed by the 2.2.5-6~exp1 upload. It is also important to use the correct -vVERSION flag in dpkg-genchanges, to make sure the correct debian/changelog entries will go in the .changes file for the upload. This is well explained in the debian-backports guidelines, but it applies to uploads to *any* suite (experimental, stable-proposed-updates, stable-security, backports, etc). For example: in the experimental upload above, you'd need to call dpkg-buildpackage -v2.2.5-5~exp1 (or pbuilder --debbuildopts -v2.2.5-5~exp1, etc) when preparing the 2.2.5-6~exp1 upload, which will get passed down to dpkg-genchanges by debhelper. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140925122100.gc10...@khazad-dum.debian.net
Re: versions / suffixes in experimental
On 25/09/14 13:21, Henrique de Moraes Holschuh wrote: On Thu, 25 Sep 2014, Simon McVittie wrote: Approach 1, which is (IMO) better when the changes you are making in experimental are truly experimental, like enabling features or patches whose medium-term future you're not sure about: 2.2.5-5+exp1, ... or -6~exp1, ... or whatever to experimental 2.2.5-6 to unstable When there is a continuity in the bug-tracking sense between 2.2.5-5~exp1 and 2.2.5-6~exp1, regardless of what your workflow is, 2.2.5-6~exp1's debian/changelog must include a merge of 2.2.5-5~exp1's debian/changelog and 2.2.5-6's debian/changelog. AIUI the general rule is that you must merge debian/changelog if and only if you merged the actual changes? In other words, if version A is an ancestor of version B (think about what the graph of branches and merges would look like in gitk or whatever), then version B must have version A's debian/changelog entry somewhere below its own. S -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54241f7a@debian.org
Re: versions / suffixes in experimental
Re: Adam D. Barratt 2014-09-25 3653b875c93fd474b8b354b4c76f4...@mail.adsl.funky-badger.org On 2014-09-25 8:16, Daniel Pocock wrote: Or should my next upload to unstable by 2.2.5-8? Or do I just ignore the version numbers I uploaded to experimental and use 2.2.5-6 as the next version number for an unstable upload, even if it doesn't contain the same things as 2.2.5-6 in experimental? No. Under no circumstances should version numbers be reused. (There's some disagreement about cases such as reintroducing old packages that aren't even in oldstable any more, but a contemporaneous upload to multiple suites using the same version number is absolutely wrong.) We recently reintroduced cl-interpol 0.2.1-1 to sid, after the package was removed in 2009. There were still around half a dozen installations reported on popcon, but the worse part is that this made the UDD changes importer explode with a unique key violation. I think they fixed it by deleting this upload from UDD, and we quickly uploaded -2 to get the package also upgraded on the old systems out there, but the bottom line should be don't do that. Christoph -- c...@df7cb.de | http://www.df7cb.de/ signature.asc Description: Digital signature
Re: versions / suffixes in experimental
Simon McVittie s...@debian.org writes: Approach 1, which is (IMO) better when the changes you are making in experimental are truly experimental, like enabling features or patches whose medium-term future you're not sure about: 2.2.5-5+exp1, ... or -6~exp1, ... or whatever to experimental 2.2.5-6 to unstable Approach 2, which is (IMO) better when the changes you are making in experimental are the main line of development, and you're only not uploading to unstable because you're trying to avoid a freeze or getting tangled into a transition or something: 2.2.5-6, -7, ... to experimental 2.2.5-5+deb8u1 to unstable (if needed) (i.e. in approach 2 you're treating the unstable branch as stable-updates to a stable release that doesn't exist yet). Either can work. I've done both in the past. Yes. To some extent it's a matter of style, and different people will have different styles, and that's okay. My personal feeling on this is that I believe people generally over-think version numbers and add more complexity than is actually required. I therefore have a personal rule that I use the simplest version numbers that I can get away with in any situation. I've not seen much practical reason to prefer the sequence: 2.2.5-6~exp1 (experimental) 2.2.5-6~exp2 (experimental) 2.2.5-7 (unstable) to: 2.2.5-7 (experimental) 2.2.5-8 (experimental) 2.2.5-9 (unstable) and the latter is simpler, so I pretty much always use that. Either way, you have to do something weird if you need to upload something to unstable from a different branch, particularly if you don't want the unstable version to be newer than the experimental version (which I almost never do). The only argument that I've found convincing for putting an exp in the experimental package versions is if they're *really* experimental, as in this may all be a horrible idea that I will disclaim in the morning sort of experimental, and it's really important to get that information in front of the user in the version number. But in general I think people are way too conservative about not just using the next version number. Integers are cheap, and you won't ever run out. :) It's akin to the problem of endless releases of software widely used all over the world that still has a 0.x version number. Just call it 1.0 already. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/874mvvqi7k@hope.eyrie.org
