Let me chime in from a marketing communications perspective on the
marketing and technical designations for our projects.
At the current point in our development I am less concerned about the
"marketing" designation since whatever term we choose should be always
used in context as a descriptor or as a verb, and not as a name. Using
a lowercase, hyphenated form, "preview-version" or "dogfood-version"
makes this clear. For example we could talk about the "preview-version
of the desktop client" having some particular feature and then refer
folks to a particular release version to try it out or to "preview"
this feature in release 0.Xx. In this case the "preview-version" of
the desktop client having this feature will span multiple releases
beginning with a particular release and continuing forward with
subsequent releases. Thus the expression "preview-version" does not in
itself refer to one particular release (that's what the release
numbers are for), but as designation of the status of the project
having reached the point where we want folks to take a look and see
where we're going.
BTW, I do like the term "preview"-version since it connotes
work-in-progress/more to come, whereas I believe Beta implies to many,
"we're done except for fixing some bugs and adding some last minute
performance and polish."
However, getting back to something Heikki noted, "...This is also
causing confusion, for example not knowing just from the use of names
how far away from release or milestone we are." [I believe his use of
the term "names" here means release version.]
As we and others begin to raise the visibility or our projects, I'd
like the user (and developer) communities to be able to easily grasp
where a particular release is in our product plan. I believe this
requires using as simple, consistent, and linear versioning scheme as
possible for all releases.
When we want to actively recruit a large number of users to "preview"
our desktop client and refer them to a particular release number, the
simpler that numbering scheme is the better. With a complex naming
scheme like the one we're currently using, (0.7alpha4) it's impossible
to guess what that number means without going back and looking at the
history.
On inspection, 0.7 implies there was a previous 0.6 version, and sets
expectations there will be a 0.8 version leading up to a 1.0 version.
And alpha4 implies there was an alpha3, but there is no way for a
casual user or new user to know how high the alpha numbering will go,
or does the use of alpha in this context imply that as some point
0.7alpha will be followed by 0.7beta, and then 0.7gamma -- and what is
our criteria for those changes?
I also agree with Ted that folks don't have time to read deeply and
understand everything we say, and may therefore jump to conclusions
based upon their own frame-of-reference when we use terms in our
version numbering like "alpha" and "beta".
Whatever versioning scheme we use for release numbers, I hope we can
be as simple as possible, consistent, use the same scheme for all the
projects, and continue to use the same scheme going forward.
Pieter
On 8/30/06, Philippe Bossut <[EMAIL PROTECTED]> wrote:
I'm going to chime in and hope not to add more confusion to the debate.
I apologize if I do.
Like others, I see 2 very different issues with the naming convention:
1- a "marketing" (i.e. external facing) issue
2- a technical issue
Let's start with 2- the technical issue. The naming scheme we are using
right now has been chosen just after 0.6 so that we could have
consistently marked milestones for both the "going to 0.7" trunk and the
"0.6 bug fixes" branches. The consensus at the time was that "0.6.<num>"
will denote an iteration of the 0.6 code base (bug fixes of some kind),
"0.7x<num>" a milestone on the way to 0.7. There was a lot of debate on
what "x" should be ("dev", "r", "a", "m", etc... note that it couldn't
be nothing since it would collide with future versions, it couldn't be
"." either since it would collide with post 0.7 bug fix releases) and we
finally took a vote and choose "alpha". Note that this was chosen to be
consistent with how PJE's egg decodes and compares the release numbers.
This is the numbering we use in the tar, dmg, eggs, svn, bugzilla,
etc... all activity where we need to mark something and understand just
reading the label where it fits in the milestone tree.
Like PJE, I think we should not change that.
The first true release of 0.7 will simply be, well, 0.7.... whatever
marketing term we use to qualify its "it's not finished yet" state...
We'll certainly have a bunch of "0.7.x" bug fix releases after that
since we'll likely have recall class bugs found by users we'll have to
fix on a stable branch. The trunk will happily hum away toward 0.8 and
start churning 0.8alpha<num> milestones on a regular basis.
1- marketing issue
I've no religion here. "beta" seemed fine to me though I agree that it
collides with the technical term (especially since we do use "alpha") so
we should stay away from it.
"Preview" sounds about right to me. I remember that when doing the first
MacIE 5.1 for OS X we called it "Technical Preview" in the splash screen
(since Apple never gave us the time to test it against the OS they
eventually released...).
This term will be visible in the Splash Screen, About box, Download
page, and PR activity.
Conclusion, I'm inclined to:
- replace our use of "beta" by "Preview" for all our marketing communication
- use "dogfood" internally when talking about our "alpha" milestones
- not change our use of "alpha" by something else in our numbering scheme
Cheers,
- Philippe
Phillip J. Eby wrote:
> At 06:06 PM 8/29/2006 -0700, Katie Capps Parlante wrote:
>> Perhaps both Cosmo and Chandler could use the "m" notation for
>> milestones between releases?
>
> I'd personally prefer to stick with using "alpha" to denote interim
> releases, as I believe those are more widely-understood terms for the
> audience(s) that those releases are directed at, and because of the
> cost/benefit of making such a change. But that might just be because
> I'm not seeing what the benefit is; it's not as if Cosmo and Chandler
> are using a common technology platform for creating releases. Perhaps
> the intended benefit of consolidation lies somewhere else that I'm not
> immediately seeing?
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "General" mailing list
http://lists.osafoundation.org/mailman/listinfo/general
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "General" mailing list
http://lists.osafoundation.org/mailman/listinfo/general
