Sorry that I'm coming late to this party...|
FWIW, I totally love the idea of naming your releases. My preference
would be go with something fun/funny (comedian names, Dr. Seuss
words?); but fun/funny is actually a pretty hard problem.
Talk of projects releasing different parts of their code on
different schedules raises a bit of a red flag with me. I assume
that issues regarding version mismatches between runtime and tools
have been considered. Is there concern that differences between
runtime and tools version numbers may cause confusion in the
Our processes really only have a concept of a project and a release.
There really is no concept of parts of a project doing a release.
This isn't a show stopper; it just means that we may need to be
creative with the process to make sure that the intent is clear. We
may need to work together to make sure we get this right. Keep in
mind that anything you call a "release" (other than service
releases) requires a release review...
Again, I assume that these sorts of issues are being considered, I
just haven't been paying close enough attention to this
On 06/17/2011 10:13 AM, Glyn Normington wrote:
Kudos to Steve Powell for coming up with
the idea. He also suggests not being too "grand" near the start.
e.g. Birds: Argus, Bantam, Canary, ...
Some more ideas if needed...
Elements: Antimony, Beryllium, Carbon, ...
Cars: Avant, Boxter, Carrera, ...
Trees: Alder, Birch, Cedar, ...
Mountains: Altai, Balkan, Cascade, ...
Colours: Azure, Bisque, Cerise, ...
Grapes: Aramon, Bovale, Centurian, ...
Islands: Aero, Batan, Capri, ...
Stars: Algol, Betelgeuse, Cygnus, ...
Any more ideas or preferences?
On 15 Jun 2011, at 11:22, Kapukaranov, Borislav wrote:
What a great idea!
Release branding will certainly add a nice
touch to the personality and popularity of a
We’ll have to find an area that has good
variety of names and won’t clash with Eclipse’s
Animals are obviously good because of the
great variety – we can take birds for example,
obviously cats are already taken J
A bird with ‘A’ is the Great Argus, which
is also known as Phoenix in some Asian areas,
which is kind of symbolic considering the dm
server and Virgo relation. J
Anyway there surely are many more options
and it would be interesting to see other
Past releases of Virgo have consisted of two or
three deliverables all at the same version number.
This is likely to be true for the next release.
However, in the future, we anticipate releasing
runtime and tooling together, a bit like a mini
release train. At that point, not all the
deliverables will have the same version number. In
fact, we want the freedom to be able to rev the
runtime and tooling independently of each other.
So in the future, release branding may become
Release branding is also a useful marketing
device. If we chose the right release brands, they
could create some "buzz" in the community. It is
also handy for future releases so we can refer to
them before we've settled on the version numbers.
Would it therefore make sense to adopt branding
for the 3.0 release so that the community gets
used to a release brand?
Examples of release branding are Eclipse and
Ubuntu with its alphabetically sequenced release
brands (based on animals in the case of Ubuntu),
Mac OS (more animals).
Counter-examples are Java (unless "Java 6" is
counted as a release brand for 1.6) and Tomcat.
I guess a Virgo release brand would get a
little messy if and when Virgo joins the Eclipse
release train as both brands would then apply to
the release. But we would expect also to release
independently of the release train, so there would
be quite a confusing sequence.
An alternative to release branding is just to
stick with the kernel version number as the
"headline" version for a release with other
components such as tooling free to have a
different version number.
What do you think? If you favour release
branding, do you have suggestions for the actual
virgo-dev mailing list
virgo-dev mailing list