Re: meeting 2008-03-19 - version numbers

[Phil Muldoon <pmuldoon at redhat dot com>]

Andrew Cagney wrote:
> a) move frysk forward to 0.8.x, from 0.0.x
>
> This is to signal that we consider all our tools are minimally at 
> alpha (key functionality is present but more to come); and for many 
> tools they are actually beta/release quality (e.g., fstack, fcore, 
> fcatch).  As fhpd and frysk mature we can move to 0.9 and 1.0.


There was quite a bit of discussion about this in the meeting.  My 
biggest issue was messaging to the user/community why we have decided to 
do this change. What is our reason for changing from 0.0.1* to 0.8. Is 
it a saner system? Are we signaling we are much more stable? In all 
aspects or just some? Anyway ...

My questions, (mercifully rendered ;) down to several points:

- I've no objection to this. It moves us to a saner versioning system.  But:

- Discussion: How/should we maintain all the tools at a similar level of 
quality, and progression. Is moving to 0.9 going to mean the that the 
UI  is in step with fcore, fhpd, and all the others?

- Discussion: What are the criteria for moving major version numbers: ie 
0.9, 1.0 and so on? Stability only? Are we going to gate version number 
on features? What's the release number to feature road-map? (there was a 
long discussion about feature embargo here which is something to really 
avoid).

- Discussion: What current tools now merit the alpha (feature complete, 
known bugs exist), beta (feature complete, no known bug exist)  and 
released state?

- Discussion: Wildcard. Because the tools are of varying maturity, which 
differs from the maturity of the ui, which differs from the maturity of 
the frysk-core, should a move to 3 (or 4 with -devel) rpms be 
considered. Right now I believe we have one srpm/spec file that produces 
3 sub-packages.

(I know a lot of these questions were asked and answered in the meeting, 
I'm just asking them here as question to answer for the the mailing list 
crowd)


> b) move to regular (monthly?) patch-level releases; e.g., 0.8.1, 
> 0.8.2, ...
I've no objections to this. But:

- What release schedule? Weekly? Monthly?

- How will we be smoke testing the results to ensure sanity (ie the last 
patch pushed screwed some stuff up). Our test cases can catch a lot of 
this?  What is the release checklist?

- Because we are moving to a more formal release deadline, how do 
development practices  change, if at all?

- What is our release matrix. Fedora 8 now, and Rawhide. But will it 
then be F8, F9 and rawhide all in sync? Will the release be to rawhide 
first, then a monthly push from rawhide to Fedora *?

- How can we detect regressions in stability and features

Overall I'm really happy to see this. There's lots to think about.

Regards

Phil