Re: Version 1 accidentally released as version 2...
On Thu, Sep 28, 2006 at 11:14:36AM +1000, Matthew Palmer wrote: On Thu, Sep 28, 2006 at 09:33:46AM +0900, Charles Plessy wrote: OK, thanks all for your answers. I will mention the problem in the README. How can I give a message only to the users who upgrade from the previous version? I do not want to annoy the ones who will install from Etch next year... If you put in NEWS.Debian (it has the same format as debian/changelog, you can even use dch to edit it) then people who are using apt-listchanges and are upgrading from a version older than the version in which the news was logged against will see the message. But that's not what he wants, because then all the people who upgrade to etch with also see it then, even though it's irrelevant for them. What he's asking is if there's a way to show it only if the upgrade is from a high enough version. If the message is important enough for a debconf note, you can use that (and display it depending on a version check in the config script). You shouldn't use debconf notes if the user doesn't actually need to do anything though. (that is, notes are annoying and should only exist because something important is happening, where some action is required from the user.) Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://129.125.47.90/e-mail.html signature.asc Description: Digital signature
Re: Version 1 accidentally released as version 2...
Le Thu, Sep 28, 2006 at 12:19:04PM +0200, Bas Wijnen a écrit : But that's not what he wants, because then all the people who upgrade to etch with also see it then, even though it's irrelevant for them. What he's asking is if there's a way to show it only if the upgrade is from a high enough version. Luckily, the situation is simpler: the package has been created recently, and six popcon-persons installed it. Only one version of the debian package has been released for the moment (i.e. the changelog has only one entry). I would like the persons upgrading to see the message and the people installing for the first time not seeing it. Will NEWS.Debian fit this purpose? Have a nice day, -- Charles -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Version 1 accidentally released as version 2...
On Thu, Sep 28, 2006 at 07:36:36PM +0900, Charles Plessy wrote: Le Thu, Sep 28, 2006 at 12:19:04PM +0200, Bas Wijnen a écrit : But that's not what he wants, because then all the people who upgrade to etch with also see it then, even though it's irrelevant for them. What he's asking is if there's a way to show it only if the upgrade is from a high enough version. Luckily, the situation is simpler: the package has been created recently, and six popcon-persons installed it. Only one version of the debian package has been released for the moment (i.e. the changelog has only one entry). I would like the persons upgrading to see the message and the people installing for the first time not seeing it. Will NEWS.Debian fit this purpose? Yes. - Matt
Re: Version 1 accidentally released as version 2...
On Wed, 2006-09-27 at 06:26 +1000, Matthew Palmer wrote: What's upstream doing about it now? Are they releasing a 2.0.1 or 2.1 or 3 or something to replace that one, or are they just sticking with the V2 package? Again, what are upstream's plans? That will have a massive bearing on what you do. Agreeing with and extending what Mathew said, I think the sensible solution would be for upstream to make a new release, in order to avoid more confusion. If that's done then you're job's simple, repackage with the new version and that's it. Make it as fast as possible though, since your users are probably a bit confused by now... and if upstream takes a while to release officially (for any reason), you could just get the CVS version tagged as 2.0, name it 2.0+1-1 or something like that and upload fast. If, however, upstream decides to not release a new tarball you repackage it yourself and use the same naming convention as above. Hope it helps. Cheers -- Leo Antunes [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: Version 1 accidentally released as version 2...
Le Wed, Sep 27, 2006 at 08:20:15PM -0300, Leo Antunes a écrit : If that's done then you're job's simple, repackage with the new version and that's it. Make it as fast as possible though, since your users are probably a bit confused by now... and if upstream takes a while to release officially (for any reason), you could just get the CVS version tagged as 2.0, name it 2.0+1-1 or something like that and upload fast. If, however, upstream decides to not release a new tarball you repackage it yourself and use the same naming convention as above. OK, thanks all for your answers. I will mention the problem in the README. How can I give a message only to the users who upgrade from the previous version? I do not want to annoy the ones who will install from Etch next year... Have a nice day, -- Charles -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Version 1 accidentally released as version 2...
On Thu, Sep 28, 2006 at 09:33:46AM +0900, Charles Plessy wrote: Le Wed, Sep 27, 2006 at 08:20:15PM -0300, Leo Antunes a écrit : If that's done then you're job's simple, repackage with the new version and that's it. Make it as fast as possible though, since your users are probably a bit confused by now... and if upstream takes a while to release officially (for any reason), you could just get the CVS version tagged as 2.0, name it 2.0+1-1 or something like that and upload fast. If, however, upstream decides to not release a new tarball you repackage it yourself and use the same naming convention as above. OK, thanks all for your answers. I will mention the problem in the README. How can I give a message only to the users who upgrade from the previous version? I do not want to annoy the ones who will install from Etch next year... If you put in NEWS.Debian (it has the same format as debian/changelog, you can even use dch to edit it) then people who are using apt-listchanges and are upgrading from a version older than the version in which the news was logged against will see the message. - Matt
Re: Version 1 accidentally released as version 2...
Le Tue, Sep 26, 2006 at 04:28:14PM +1000, Matthew Palmer a écrit : On Tue, Sep 26, 2006 at 02:44:14PM +0900, Charles Plessy wrote: For one of the packages I created, the upstream sources I used were a version 1.x accidentally released as version 2.0 on sourceforge. Accidentally? Well, SourceForge was offering poa_release_2_0.tar.gz for a few months, and it recently changed to poaV2.tar.gz. I contacted the upstram author, and he explained me that poa_release_2_0.tar.gz was supposed to contain sources tagged release_2_0 in their CVS repository, but in fact contained an older version. My first version of the package is poa_2.0-1, and is based on poa_release_2_0.tar.gz, which is not version 2.0. Have a nice day, -- Charles Plessy http://charles.plessy.org Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Version 1 accidentally released as version 2...
On Tue, Sep 26, 2006 at 02:44:14PM +0900, Charles Plessy wrote: For one of the packages I created, the upstream sources I used were a version 1.x accidentally released as version 2.0 on sourceforge. Accidentally? Did you package and upload this new upstream release? Has upstream gone back to numbering their releases as 1.x? I don't really understand the problem. It sounds like there's a new major version of the software, which is incompatible with the old version, but that's not very accidental. The differences between the two versions are quite high, as the file formats accepted in input have changed (some added, some removed). I am wondering what I am supposed to do in this case : a) Release a different package which conflicts on the previous, or Perhaps, if the changes are major enough that silently upgrading is likely to deeply annoy some people (or if the program has effectively forked and 1.x is going to continue being developed alongside 2.x). The conflict is only required if both packages are going to provide files of the same names. b) use an epoch and upgrade the current package as version 2.0, or I don't understand what problem you're trying to solve, exactly, but this would only be necessary where you accidentally packaged a 2.x release when upstream is really still only making 1.x releases. c) ask upstream to increase the version number (for instance they could include add the manpages I wrote for the program) and upgrade then. That's another possiblity, but it depends greatly on what exactly upstream have done, whether they consider it to be a problem as well, what their plans are in general, and what sort of relationship you've got with them. The options b) or c) could be accompagned by a NEWS or something equivalent if this is not an abuse, to tell that there has been a major version change and that scripts could break. An item in NEWS is a good idea if people could suffer problems on the upgrade. I would favor option a), but if upstream becomes suddently mega-active and releases a major version every half year, this could be a mess. I don't see the problem with just making a new version of the existing package, automatically upgrading as much as you can, and warning users that Things Have Changed. But I really don't understand the exact problem that you're having. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Version 1 accidentally released as version 2...
On Tue, Sep 26, 2006 at 05:09:51PM +0900, Charles Plessy wrote: Le Tue, Sep 26, 2006 at 04:28:14PM +1000, Matthew Palmer a écrit : On Tue, Sep 26, 2006 at 02:44:14PM +0900, Charles Plessy wrote: For one of the packages I created, the upstream sources I used were a version 1.x accidentally released as version 2.0 on sourceforge. Accidentally? Well, SourceForge was offering poa_release_2_0.tar.gz for a few months, and it recently changed to poaV2.tar.gz. I contacted the upstram author, and he explained me that poa_release_2_0.tar.gz was supposed to contain sources tagged release_2_0 in their CVS repository, but in fact contained an older version. My first version of the package is poa_2.0-1, and is based on poa_release_2_0.tar.gz, which is not version 2.0. What's upstream doing about it now? Are they releasing a 2.0.1 or 2.1 or 3 or something to replace that one, or are they just sticking with the V2 package? Again, what are upstream's plans? That will have a massive bearing on what you do. - Matt
Version 1 accidentally released as version 2...
Dear mentors, For one of the packages I created, the upstream sources I used were a version 1.x accidentally released as version 2.0 on sourceforge. The differences between the two versions are quite high, as the file formats accepted in input have changed (some added, some removed). I am wondering what I am supposed to do in this case : a) Release a different package which conflicts on the previous, or b) use an epoch and upgrade the current package as version 2.0, or c) ask upstream to increase the version number (for instance they could include add the manpages I wrote for the program) and upgrade then. The options b) or c) could be accompagned by a NEWS or something equivalent if this is not an abuse, to tell that there has been a major version change and that scripts could break. I would favor option a), but if upstream becomes suddently mega-active and releases a major version every half year, this could be a mess. I welcome any opinion or advice on this question. Have a nice day, -- Charles Plessy http://charles.plessy.org Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
