On Sep 28, 2014, at 1:13 PM, Sébastien Villemot <sebast...@debian.org> wrote:
> 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…). I’ve added a couple of notes about setting “staged” to the Release_Process wiki, which I use every time so that I don’t forget something. Regards, John Ralls _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel