Hello,
Yuval, have you taken a look at git <http://git-scm.com/>? Much of the
workflow you suggest lends itself to a DVCS model (Distributed Version
Control). I use git along with 'tailor<http://progetti.arstecnica.it/tailor>'
to hack on Hugin. When I was working on bugs, I would create a branch for
each issue. Then, as I worked on the feature, I could keep up to date with
the trunk, merging as necessary. Once the fix was ready, I would diff
against the current truck, create a patch and commit it to a pristine SVN
checkout. When one starts considering branching and merging, dvcs systems
like git and darcs really come into their own.
As for ideas on how to release software I have a few (doesn't everybody!)
- keep development in trunk
- develop large features in a separate branch and merge in when they work
well enough for testing
- We are not in a release cycle, bug fixes can be applied directly to
trunk
- When enough features are in place for a new release create a branch
- release builds of this branch frequently (aids in getting testers)
- no new features added
- merge bug fixes back to trunk as required (changes in development
may discount the need)
- once all bugs are deemed fixed or postponed then string freeze
- release
- Development continues on in trunk/feature branches while the release
branch is finalizing
I don't have much experience with branching in SVN, but I had a lot with
CVS. It was hell. Perhaps SVN is better at merging than CVS...
- Gerry
On Mon, Jan 26, 2009 at 12:14 PM, Yuval Levy <goo...@levy.ch> wrote:
>
> Bruno Postle wrote:
> > On Sun 25-Jan-2009 at 13:16 -0500, Yuval Levy wrote:
> >> By submitting his patch, Lukáš asked for a review. I confirm on both
> >> Ubuntu and Windows. Does not break anything. I vote to put it in trunk.
> >
> > Yes put it in the trunk, it isn't going to get extensive testing any
> > other way.
>
>
> The recent discussion about merging patches or branches into trunk got
> me thinking.
>
> Branching out does not always have to be in the public repository. Every
> checkout is potentially a branch.
>
> I'd like to propose the following way of working, which is mostly a
> formalization of what has been done so far.
>
> Let's work with three types of branches:
> - development branches
> - release branches
> - trunk
>
>
> DEVELOPMENT BRANCHES
>
> Development branches can be either public (in SVN) or local, if a
> developer is more comfortable working on his own local copy.
>
> The more the merrier. We should facilitate users and developers toying
> with the code. They should know that what is under "branches" in the
> repository can be highly interesting. We should provide them with
> hacking howto's like
>
> <http://ultrawide.wordpress.com/2008/11/16/hacking-hugin-part-1/>
> <http://panospace.wordpress.com/2008/12/30/vedutismo>
>
> to guide them into the depth of the code without fear. Once they will
> discover the joys of hacking, they are more likely to become contributors.
>
> In terms of management, I'd set a policy of keeping the branches
> relevant by cleaning up / closing dev branches when the code flows back
> to trunk or when the branch is abandoned / becomes obsolete.
>
> The definition of abandoned branch for me would be if it has not seen
> any write activity for six months. Before closing it I would ask
> publicly (here) if somebody still intends to work on it, and as a
> closure I would move it to a separate folder called abandoned-branches.
>
> A branch becomes obsolete when the feature for which it was started has
> either been integrated in trunk or the branch has been superseded by the
> development and it is easier to implement that feature starting from
> scratch. In those cases I would delete the branch, to avoid users
> wasting time on them. This would apply to branches in both branches and
> abandoned-branches folder (as it does not make sense to pick up an
> abandoned and obsolete branch).
>
> The goal is to keep the branches folder clean so that when an outsider
> hits it instead of trunk he is not wasting time.
>
>
> TRUNK
>
> Trunk is the main experimental branch. the policies I suggest adopting
> for trunk:
> * it should build for most supported platforms most of the time, but the
> occasional break is acceptable.
> * the passage of code from a dev branch to trunk should be fast and
> uncomplicated. I'd rather see a feature first in trunk and then bugfixed
> than the other way around.
>
> I propose a simple test to decide if code can move from a dev branch to
> trunk:
> * the owner of the dev branch declares his work finished - meaning that
> it works for him
> * at least one reviewer test it on a different platform and finds that
> nothing major is broken
> * the code is not harmful, i.e. it does not break existing functionality
>
> Once in trunk, the code will be exposed to broader testing and review,
> which will reveal bugs and minor functionality break.
>
> Occasionally there will be snapshot releases from trunk. All other
> releases will come from the release branches.
>
>
> RELEASE BRANCHES
>
> I'd be very strict about changes to release branches. No new features,
> just bug fixes to the features that were present at the moment it was
> branched out from trunk.
>
> This is the place to add missing translations and support for not yet
> supported platforms.
>
> It is from these branches that the actual releases will be tagged,
> tarballs will be created. This includes alphas, betas, release
> candidates, final releases, bugfix releases.
>
> Alpha: really just a tentative and not much better than a snapshot. Must
> not yet support all languages and platforms and is highly experimental.
> Old functionality should work as expected, but new functionality is in
> alpha stage.
>
> Beta: supports main languages and main platforms. Most functionality
> should work, but there still are bugs.
>
> Release Candidate: reproducible bugs scheduled to be fixed for the
> release are gone. Difficult to reproduce and exotic bugs can still
> exist. This is the time to polish things up. All translations should be
> in at this time.
>
> Final Release: supports all languages and all platforms.
>
> Bugfix Release: in case important bugs are fixed in trunk later and are
> backported. Not very likely, since we don't have much resources and it
> is anyway better to move to the next release cycle.
>
>
> PRACTICAL IMPLICATIONS
>
> In that sense, I would suggest branching out now 0.8. This would freeze
> the features of 0.8 (i.e. no nona-gpu and no vigra 1.6) and its strings.
> There is enough food on the plate with PTbatcher, fast-preview, Celeste.
> And for the next release the main dish will be nona-gpu + vigra 1.6.
>
> This should enable focussing on the polishing, clean-up, bugfixes for a
> release on the release-0.8 branch until we can tag a release-0.8.0.
>
> At the same time, the bleeding edge can keep evolving in trunk with the
> addition of vigra1.6 and soon nona-gpu.
>
> there is only one complication to this, which is that from the moment we
> branch out 0.8 bugfixes will need to be applied to both branches - 0.8
> and trunk. The alternative would be to freeze trunk for the time it
> takes to fix those bugs deemed critical for the 0.8 release and delay
> broader testing of vigra1.6 and nona-gpu. Both ways are OK for me.
>
>
> In practice, I'd clean up the branches folder by:
>
> 1. closing the following branches:
> - before_gsoc2007/ (obsolete)
> - dangelo (last change 5 years ago)
> - gsoc2008_batch_processing/ (successfully integrated in trunk)
> - gsoc2008_integration (superseded by trunk)
> - gsoc2008_opengl_preview (successfully integrated in trunk)
> - gsoc2008_sky_identification (successfully integrated in trunk)
> - stable (obsolete)
> - vigra140-branch (obsolete)
>
> 2. opening a release-0.8 branch when we are ready, from which eventually
> 0.8.0 will be tagged
>
> 3. keep on working on the work in progress development branches with the
> goal of integrating them in trunk
> - gsoc2008_feature_matching
> - gsoc2008_masking
> - nona-gpu
>
> 4. to be really anally retentive, I'd clean up branches into:
> -branches/dev/
> -branches/releases/
> -branches/abandoned/
>
> moving the three branches mentioned in 3. to branches/dev; and moving
> release-0.7.0 branch in branches/releases/
>
> 5. in tags, I would add a tag to hugin-0.7.0 (tagging the exact SVN
> revision used for that tarball), and in the future I would tag each
> tarball before releasing it - tagging against a release branch, not
> against trunk.
>
> 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 hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to
hugin-ptx-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---
