Le dimanche 28 septembre 2014 à 12:53 -0700, John Ralls a écrit : > On Sep 28, 2014, at 12:30 PM, Sébastien Villemot <sebast...@debian.org> wrote: > > > Le dimanche 28 septembre 2014 à 12:21 -0700, John Ralls a écrit : > >> On Sep 28, 2014, at 10:29 AM, Sébastien Villemot <sebast...@debian.org> > >> wrote: > >> > >>> Le dimanche 28 septembre 2014 à 10:04 -0700, John Ralls a écrit : > >>>> On Sep 28, 2014, at 9:49 AM, Sébastien Villemot <sebast...@debian.org> > >>>> wrote: > >>>> > >>>>> Le dimanche 28 septembre 2014 à 11:34 -0500, Tommy Trussell a écrit : > >>>>>> I just noticed GnuCash 2.6.4 has been uploaded to Debian Unstable, but > >>>>>> haven't seen a notice here or on the GnuCash.org web site for the > >>>>>> release > >>>>>> of 2.6.4. > >>>>> > >>>>> I indeed uploaded to Debian the 2.6.4 tarball that is available at: > >>>>> > >>>>> http://sourceforge.net/projects/gnucash/files/gnucash%20%28stable% > >>>>> 29/2.6.4/ > >>>>> > >>>>> If I was so quick to notice it, it's because the release had been > >>>>> announced long in advance > >>>>> (http://wiki.gnucash.org/wiki/Release_Schedule) and also because the > >>>>> Debian "Jessie" freeze is getting close and I did not want to miss the > >>>>> deadline. > >>>>> > >>>>> I guess the release announcement is currently being prepared. > >>>> > >>>> The release has not yet officially happened, it’s waiting on the Windows > >>>> and Mac builds. Tagging the release and staging the tarballs has to > >>>> happen the night before the release to set up for those builds. If > >>>> you’ve already released the tarballs to Debian please pull them until > >>>> after the announcement hits the lists. It’s quite possible that a > >>>> problem with either of those builds will cause me to make changes to the > >>>> tarballs which would make your Debian package mismatch the official > >>>> release. > >>> > >>> It is too late for this release, but I'll wait for the official > >>> announcement for the next releases. > >>> > >>> However I think that you should not publish on SourceForge source > >>> tarballs that are not considered as final releases. This is very > >>> confusing, and can lead to all sorts of misunderstandings and problems > >>> (as happened to me). Either use a different numbering scheme (like > >>> release candidates with a -rcN suffix), or keep them private. > >> > >> It’s only confusing because you jumped the gun and grabbed the tarballs > >> before I announced the release. But I just experimented with the “staging” > >> feature which lets me hide directories (you shouldn’t be able to see 2.6.4 > >> in the list, though you can still get at it if you type it into the URL > >> bar). I’ll use that from now on. > > > > Well, it's confusing because the unreleased tarball is at the exact same > > place and with the exact same filename than the final tarball! And I > > have a script that automatically checks for new tarballs at that place > > (as do most packages in Debian and other distributions). > > > > Anyway, thanks for considering to use a private directory from now on. > > That should fix the issue. > > > > For the 2.6.4 case, please let me know if you modify the source tarball. > > In that case, I will reupload the new tarball in Debian (with a slight > > modification of the Debian version number, something like 2.6.4+final). > > I don’t know what other Debian builders are doing, but I’ll note that GC2.6.4 > hasn’t showed up on Fedora or OpenSuse. Besides, you said earlier > > > If I was so quick to notice it, it's because the release had been > > announced long in advance > > (http://wiki.gnucash.org/wiki/Release_Schedule) and also because the > > Debian "Jessie" freeze is getting close and I did not want to miss the > > deadline. > > So which is it, automatic script or you being too eager?
It's a mixture of both: the script notified me about the new release; then I took the decision to upload despite the lack of official announcement (releases are never uploaded automatically to Debian, for obvious reasons; there is always the need of human intervention). > If it’s really an automatic script, I doubt setting staged on the SF > directory will fix the issue because your script won’t see that. Ours don’t, > and download the tarballs just fine. I verified that the modification that you made works for me. The scripts looks at the top-level sourceforge HTML page and scans for new subdirectories; since you have hidden the 2.6.4 directory, it is no longer seen. > Having the same name and same place is necessary because our scripts for > building need to point to that same place, otherwise they have to be updated > twice: Once to build the package and again so that others can use them after > the release. I understand that it is easier that way. I guess you could nevertheless have an option to select whether to build from the public location, or from a private staging area. Anyway, the solution that you have already implemented works for me (as long as you don't forget to do the same in subsequent releases…). -- .''`. Sébastien Villemot : :' : Debian Developer `. `' http://www.dynare.org/sebastien `- GPG Key: 4096R/381A7594
signature.asc
Description: This is a digitally signed message part
_______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
