Hi all, I have followed the discussion in the previous thread (was: reference), but I'm still lost.
To what branch do I now have to apply patches/changes? 2009.2 has been created a couple of days ago (or so). Thereby, the standard trunk has become 2009.3 being the unstable development trunk. Now, when I apply patches I will do that to the trunk, thereby to the unstable development version (do I?). Is there now a "super admin" who decides what goes into 2009.2 (being the stable one). If so: Is there a planning when we going life with this stable one and "what's in it"? W.r.t. to the stable one and when not having a super admin: Do I have to apply "stable" changes like the dutch translation from this morning and a Xcode related Hugin version upgrade to both trunks? W.r.t. the latter: I set versioning for XCode to 2009.3 (the trunk): I now see that this patch has also been applied to the stable trunk 2009.2, but that's not correct, which means it's not a stable change. Please give some advice. A completely and utterly lost, Harry :-D 2009/8/2 Yuval Levy <[email protected]> > > Bruno Postle wrote: > > On Fri 31-Jul-2009 at 23:31 -0400, Yuval Levy wrote: > >> no freezes on trunk, ever? > > > > That's the point of stabilising releases on branches. > > excellent, we have a deal! > > I started to clean up branches/ by creating releases/ and moving out > there the releases > > > >>> Next stable branch is 2009.2.0 as soon as it branches, trunk becomes > >>> 2009.3.0 at the same time. > >> Just to make sure we're on the same page: the branch becomes 2009.2.0 > >> *before* it is actually stabilized? (see the attached image that depicts > >> how I envision the interface between the development and release > cycles)? > > > > Yes, there is no need to create new version numbers between branch > > points. > > ok. I am currently running some tests. If they are successfull I will > merge nona-gpu into trunk. Right after that I will branch out 2009.2.0 > > > > For a release candidate you only want to rename that tarball to > > hugin-2009.2.0_rc1.tar.gz but internally it is unchanged. If you > > decide to make it the final release, just rename it back again and > > reupload. > > > > It makes sense to do beta releases the same way, just put _beta1 in > > the tarball filename before uploading it. > > thanks for explaining how to do this. > > > >> 4. tag the current revision of the new release-codeline for release > >> (snapshot) > >> > >> $ svn copy > >> https://hugin.svn.sourceforge.net/svnroot/hugin/hugin/releases/2009.2 > >> > https://hugin.svn.sourceforge.net/svnroot/hugin/hugin/tags/snapshot-2009.2.0.YYMMDD > >> -m "Branching 2009.2 for snapshot" > > > >> 5. package and release snapshot > > > > I wouldn't bother with the 'tag' since the svn number serves the > > same purpose, but if you do tag it needs to be the other way around: > > not really. it's svn number + codeline. each codeline exists at a > specific svn number, so we'd have to specify /releases/2009.2 @ SVN. A > tag is a convenience operation. > > > > > 4. create snapshot tarball, note svn number. > > > > 4a. build tarball to make sure it isn't broken at a basic level. > > > > 5. rename and release tarball snapshot. > > > > 5a. `svn copy -r 1234 ...` to create a tag for future reference. > > Don't put the date in the tag name as this is easy to determine, use > > the alpha/beta/rc name as this is what people will use. > > OK. With tagging, your way. > > Yuv > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/hugin-ptx -~----------~----~----~----~------~----~------~--~---
