Hi,
Thanks for the comments,
It's kinda hard to reply individually, so here I wrap up the comments given so
far:
1) The version numbers and release dates
> Here's an example list of version numbers and release dates when FlightGear
> will
> be released quarterly.
>
> 2.0 - at the end of March, 2009
> 2.1 - at the end of June, 2009
> 2.2 - at the end of September, 2009
> 2.3 - at the end of December, 2009
James:
> It's not quite the number system I first guessed at, and I think the
> odds of ever *doing* a bug-fix release are quite low, but it sounds
> reasonable.
Stuart:
> A roadmap would be a great idea. However, I'm not sure a quarterly release
> cycle
> is realistic. Allowing for a 2 week RC test, you're talking about less than 3
> months
> of actual development between releases. That's not much time.
Tim:
> This is a good idea, regardless of the specific milestones that make it into
> a
> release. It seems to me that just the data tree sees enough new development
> that
> quarterly releases would have interesting new content.
So having such version numbers are acceptable but we have more room on
determining the release cycle.
To me quarterly release cycle is reasonable, plus you don't have to promise
100% completeness on a certain feature for each release.
Almost all open source software have some bugs in each release, so we don't
have to seek for such perfect project that none can reach.
There're some preferences for version numbers, but all the comments are not
against the version numbers I listed as examples.
So my idea may be acceptable, I think.
I want to collect more opinions on the release cycle. Which do you prefer,
semiannual or quarterly? and why?
>> 2) Milestones (Goal for each release)
>> Here's an example list of "must-achieve" things for 2.0.0 (based on
>> discussion
>> on the list, I believe).
>>
>> [2.0.0 - at the end of March, 2009]
>> Functionality:
>> - Landing Lights
>> - Shadows
>> - More improvements in 3D clouds (I don't know the exact goal on this
>> though...)
>
Stuart:
> These seem like sensible goals for a 2.0 release. However, they appear to be
> very dependant on Tim and myself.
> (snip)
> Pushing for a release in 3 months without any commitment from the
> developers involved in the main feature improvements is pretty high risk.
Tim:
> This sounds nice, but we, or at least I, can't commit to specific features or
> development on a fixed timescale.
James:
> Overall I agree, coming from a commercial software development side,
> I'd prefer people to think in terms of features, and committing to
> delivering them for a certain release. Where a feature means the kind
> of thing we'd put in a 'new for this release' bullet point list. Then
> we can decide whether to delay a release because feature X will take
> an extra two weeks, or postpone feature Y from release 2.n to 2.n+1
> because it would delay it too much.
So maybe "Must-achieve" is a bit too tight. What about listing features that
you (will) start working
instead of "must achieve." That also work. This way there's no commitment of
achievement on each release,
but it rather says you are or will be start working on a listed feature on a
certain release.
We cannot seek for the 100% completeness at the end of each release, but it is
a good idea to show that we have a certain set of features
regardless of completeness. we can keep improving such features in the versions
follow.
How's this?
About the milestone document, we can put these in either wiki or cvs.
Maybe there's no perfect place so we can start writing such things to wiki with
a clear note like "developers only."
By the way, are there any features that can be implemented on 2.0.0?
>> 3) Release branch
>> I believe that we need to have a release branch for both developers and
>> release
>> organizers.
>> The main reason is to separate bug fixes from implementing a new features.
>> This
>> way, developers don't have to wait for the release
>> to check in attractive but likely buggy code to cvs. Usually you must not
>> include a new feature to the release branch once it is created.
>> However, if many developers want to include one to the release branch, then
>> we
>> can discuss it in the list.
>> After each release, we'll merge the bug fixes to trunk. If we get used to
>> this
>> release process, maybe a branch exists only for a few weeks,
>> and thus merging changes to trunk is not gonna be that hard.
>
James:
> I think in practice, the odds of ever doing a release *branch* for a
> project like FG is very low. I'd rather just stabilise trunk and tag.
> If we ever needed to do a x.y.1 release, it's trivial to branch from
> the tag and fix the bug. In general, back-merging from a release
> branch to a trunk is a horrible, thankless task, so avoiding it seems
> like a win to me.
Stuart:
> I think cutting a release branch just prior to the release makes sense, but
> having long-term
> release branches and only merging from trunk when you're confident a feature
> is finished
> and bug-free is going to be a piece of bureaucracy that will turn developers
> away.
>
> I suspect we'd end up in much the same place we were in prior to the 1.9
> release, where a large
> segment of the user population was using CVS snapshots because that is where
> all the cool
> features are.
>
> Bear in mind that we're still on CVS, so merging isn't as easy as with SVN.
> Particularly if the
> release branch differs significantly from trunk CVS.
Tim:
> I think this is a very good idea, and the work like shadows could start going
> into a "bleeding edge" branch soon. I think we need a "stable" branch, even
> with
> quarterly releases; new code and fixes are checked in all the time that our
> power users want, even if they aren't willing to break their world with
> experimental stuff.
>
> That said, I cannot bear the thought of setting up this parallel branch
> structure (to say nothing of the plib branch, that sees some fixes from time
> to
> time) in CVS. I know it's possible in CVS, I've worked on many hobby and
> professional projects that use CVS branching, and there is always some fiasco
> that happens in the course of making or merging branches. I don't have the
> bandwidth to deal with those headaches on a hobby project. Thus, I won't
> support
> a bleeding-edge branch until we move to a revision control system that
> properly
> supports branching.
>
> We can debate this 'til the cows come home, but Git is the only rational
> choice
> for a replacement VCS. It has the features, the community, and today has the
> user friendliness and Windows support to be used by everyone who wants to
> compile current FG development sources. It is already being used by a
> critical
> mass of
Branching and Merging are not that easy, but I think we can do it.
However, I don't think we need persistent stable / unstable branches. Having
trunk with a branch only for a release is enough.
If cvs doesn't work good in merging, then we can use some other tools.
One easy way is to use a local svn for just merging a branch to head.
For example, you can do so by:
1) first check in the source in the branch point on cvs to svn
2) then make an svn branch
3) checking in the head of trunk in cvs to svn head.
4) check in the end point of cvs branch to svn branch.
5) svn merge branch_point branch_end . (assume we have svn head in working
copy) will get the job done.
(if there's no conflict).
This is just an idea.
Anyway, as Stuart said, I think having a month of release branch can be good in
terms of improving the quality of FlightGear.
We still have some SIGSEGVs and sudden crashes that could be fixed during the
release process.
So if we go with semiannual release cycle, then I do agree with Stuart's idea.
I also want some other developers' opinions or suggestions on all of these
above.
Thank you,
Tat
------------------------------------------------------------------------------
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
