> > Anyway I shouldn't have brought up the subject, this is way off
> > topic.
>
> I don't think so - how we organize ourselves is very much on topic.
For what it's worth, I'd weigh in that what Yuval's proposing for the layout
seems to make sense to me. The layout I'm accustomed to is akin to:
root/
tags/
0.7.0/
0.7.1/
0.8.0/
0.8.1/
0.8.2/
branches/
0.7/
0.8/
dev/
feature-a/
feature-b/
feature-c/
trunk/
The process I'm most accustomed to with SVN is:
1) Main development happens in trunk
a) ... except when it involves significant rewrites or experimental
features, which begin in dev branches first
2) Trunk is "ideally" kept compliable for nightlies - This is more about
quality control than anything. Trunk being in an unstable state for more
than a day or two often creates more headache, and suggests the feature may
have been better beginning in a branch.
3) When certain objectives are met (either certain functionality goals being
in place, or general timing), trunk is branched into a candidate branch
4) The branch is stabilized (which should already be so, more or less), with
RCs coming from it.
5) A release is made from that branch when it is agreed to be stabilized.
Optionally, it is tagged as well (which is more for convenience than
anything - Again, it's "cheap", and allows you to instantly find/browse the
code for that release)
a) Changes from that branch may either be periodically merged back
into trunk during stabilization, or it may wait until the end.
6) Where do you put ongoing maintenance? There are several philosophies to
this approach:
a) The fixes start in the oldest "maintained" branch, and are
successively merged forward through the branches. This is generally easy
because each successive version is based on the code that preceded it, so
there may not be as many conflicts. I've seen this on several commercial
projects - You generally only have conflicts when merging old->new and new
was rewritten.
b) The fixes start in trunk, and are then (back-)ported to the
various branches. This ensures that the fix for each branch is correct for
each branch, but runs the risk of conflicts because newer code may have been
substantially altered/refactored, and working backwards may not always be
easy. Depending on the nature of the bug/fix, this may ensure better quality
(by ensuring every fix is appropriate for each branch, rather than just
straight merging), but may introduce more complexity (every merge conflicts
from new->old if new was rewritten)
c) Fixes only go into trunk. The maint branches are treated more
like tags/stabilizers than statements of product "versions". Major
development happens out in dev branches.
I've seen b) used frequently in cases where there are issues of
API/compatibility. You want to keep the API stable for consumers of it,
while at the same time, you want to fix bugs/security holes. PHP is an
example of this.
However, given that Hugin isn't really exposing APIs, and versioning of the
project files themselves is largely a non-issue because they rarely change
and is fairly standard, it sounds like c) is the better approach.
The challenge in deciding how to do "step 6" is, in my mind, largely
dependent on what you define a "minor" version to be. The question is: "What
is the difference between Hugin 0.8.0, 0.8.1, and 0.9.0?" Does 0.8.1 *only*
address bugs and will never introduce new features? Then maybe a or b are
the best approaches. Is Hugin 0.7.0 still "supported" when 0.8.0 is
released, meaning bug fixes still need to make it in and a Hugin 0.7.1 is
eventually released? Then again, maybe a or b are the best approaches. Or is
the difference between 0.8.0, 0.8.1, and 0.9.0 that "some" new features are
introduced between 0.8.0 and 0.8.1 (in addition to bug fixes), but that a
longer-term rewrite of some core piece along with major new features is
0.9.0. If that's the case, then I'd say c probably sounds the most
manageable, and it sounds the most akin to how the current dev lifecycle is.
The question about versioning doesn't disappear by using a date-based
alternative. In fact, I'd wager the date-based approach loses some of
utility in communicating to people what the differences between "A and B"
are. After all, "Major.Minor.Rev" is a well understood paradigm, even if
there is significant debate over what is "major" and what is "minor".
Date-based just communicates that X is newer than Y, but that doesn't
necessarily mean "better" or more "stable". It also depends heavily on
having a well-defined roadmap so you have an understanding of what can/will
and cannot/will not make a particular release. Look at Ubuntu, the numerous
meetings held for steering to maintain the 6-month active release and 2-year
LTS release schedule, and you start to think Hugin is not quite there yet :)
Equally part of the conversation seems to be "What constitutes a release?"
Is it goal/milestone driven, that the release is ready when features X, Y,
and Z are finalized and stabilized? Is it date driven, such that you get
whatever features can be brought in/stabilized in a x-Month period? Or is it
on island timing, where a release is ready "when it's ready" and it contains
"what it should"? All are perfectly viable and respectable answers, but each
approach will have impact on the file structure and versioning in big ways.
Regardless though, structurally, it seems to make sense to separate out the
"branched for historical but not changes should be made" from the "branched
for maint/stabilization" and the "branched for feature development" and
trunk. This would seem to solve Bruno's concern over an svn up on a branch
dir adding hundreds of megs, especially if someone's primary concern is with
stabilizing a branch rather than poking and prodding on some
latest-and-greatest feature-branch.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
