Re: The next Gnome Office release.

[Ryan Pavlik <abiryan ryand net>]

Mark Gilbert wrote:

> I know I'm being a prick but let's make sure everything's clear here
> because it apparently isn't:
> MAJOR.MINOR.MICRO.NANO.PICO, right coders?
>
> On Tue, 2004-03-30 at 20:21, Charles Goodwin wrote:
>  
>
> > On Tue, 2004-03-30 at 19:17 -0500, David Bolack wrote:
> >    
> >
> > > On Tue, 2004-03-30 at 18:31, Charles Goodwin wrote:
> > >      
> > >
> > > > I think that every time a GO application gets a minor version bump, we
> > > > should quiety bump the GO version number.
> > > >        
> > > I'm of the firm opinion that GO should only bump when two or more
> > > components do a minor stable revision. ( 1.2 to 1.4 etc ) and *only*
> > > then.  If depends change/increase, or revisions are *major* then go up a
> > > whole number.
> > >
> > > Non-geeks really get a little confused by the layers of subversions.
> > But I think it's important to diligently update GO with each GO app
> > release because every incremental minor application release usually
> > fixes blocker or crasher bugs that will cause people problems.
> >
> > By quietly upping the minor version number, we'll be ensuring that
> > people new to GO will be acquiring the _latest_ stable versions of
> > applications and hence getting the best possible experience.
> >
> > It will also give us a way to keep older GO versions up to date.  Whilst
> > we might be working with the 1.2.x releases, we could keep 1.1.x
> > releases coming out for the sake of people who are (to whatever degree)
> > dependent on the 1.1.x set of GO applications.
> >
> > Oh well, I've made my point.  Just an idea.
> >
> >    
I think Charles brings up a good point here: integration is seen as
weaker when a "better", newer version of a program is available
separately than can be gotten through the suite.  I also see the view
that too many "micro" versions will be confusing. So, here is an idea,
complete with new terminology...
Updates to either the Major or Minor version number (such as 1.0 to 2.0
or 2.0 to 2.2), such as a new "stable" series (for Abi at least), are
hereafter known as "Big Upgrades".   Micro versions (2.0.6) that feature
critical/common bug fixes that most users will want are hereafter known
as "big _updates_".

GO increments to a new Major or Minor version as a suite when sufficient
core applications have completed a Big Upgrade, and developers deem it
time for a new series (new deps, etc...), at developer's discretion.
Each big update of a core app that is seen as essential (like 2.0.5
pretty much was for Abi Win32) will cause the release of a new Micro
version number of GO, packaging all the latest updates at the time of
release.  On the GO site, along with the official most recent Micro
version, users have quick access to "individually update" components of
GO that have had Micro/bug fix versions released, without leaving the GO
web site.  This could be as simple as a link to the download from the
project site, or more complex (auto downloader, some sort of scripted
packager, or whatever.).  These updates preferably would change some
value allowing their presence to be easily noted in bug reports without
anyone blinking at it.  That way, the 'average user' will get the
essential big updates, not be overwhelmed by a GO v1.2.45sp9, and those
with special needs that require a bug fix can still get it from the
"official" GO source, providing a solid, stable marketing front.  Users
will not need to dig through each project's site in order to get the
"latest and greatest", but we maintain control over a sane pace of
standard, full packages.

How does this sound?  It shouldn't be _too_ much more work for the
packagers, since the "little updates" (non-big micro versions) of each
app are packaged anyway, and could just be linked for simplicity.

Thoughts? Comments? Flames? Jests?

Hope this makes sense...

Ryan