Hi all,

sounds good, additonal I would like to see a process (or naming convention)
for bug fixes also for the GA version.

The bug could be fixed with releasing a new GA or special fixes could be
delivered where only parts of the GA where replaced (like jars or even
classes).

I think it is needed to list and may be deliver separate fixes because of
the dependency to the hole plattform and may be to custom API use.
Some customers would like to fix problem A but will not load fix for problem
B, also fixes could depend on other fixes. That would be the optimium but is
costly to handle.

When compatibility is given (and that is what the Kettle developers always
have in mind ;-) the complexity could be minimized and simply a GA with
subsequent fixes could be delivered.

So in summary I propose to have a GA with a build ID and a list of fixed
bugs within this GA.

At this time we already have a build ID and a list of fixes that where
implemented within the latest version (Kettle trunk). What we would need is
a list of fixes that went backward from the Kettle trunk to the GA-tree.

What you think?

Have a great day!
Jens




_____

Von: kettle-developers (AT) googlegroups (DOT) com
[mailto:kettle-developers (AT) googlegroups (DOT) com] Im Auftrag von Matt Casters
Gesendet: Montag, 5. Februar 2007 13:07
An: kettle-developers (AT) googlegroups (DOT) com
Cc: 'Jay Meldrum'; 'Jacob Cornelius'; 'Doug Moran'
Betreff: Kettle Release management


Dear Kettle developer,

Over the past year more and more people and companies have been getting
involved in Pentaho Data Integration (PDI a.k.a Kettle).
Where intially it would be just a few developers and a few users, the list
of "consumers" is now becoming larger every day: developers, users,
companies, vendors, partners, trainers, documenters, translators, .....
Because of that, we from Pentaho are convinced that it's not a bad idea to
go with some sort of basic release management.

The release management system we have in mind to deploy is the sort of thing
that corresponds best to what we've been doing already:

A) Add features to a stable version in batches.
B) Reach a certains state where you (aim to) stop adding new features (code
freeze)
C) Iron out the problems and release as many 'somewhat' stable versions to
showcase the new functionality and stabelize the codebase.
D) Release the software as stable.

In general, this is the sort of thing that we've been doing in Kettle for a
while now although it was never formalized and communicated like that to the
outside world.
Because that communication becomes more and more important we propose to do
more of that by changing the naming convention of our software:

A) Build and release Mx (milestone) versions at regular times: it works, but
is not feature complete nor stable
B) Build and release a FC (feature complete) version: it works, is feature
complete, but by no means whatsoever stable.
C) Build and release RCx (Release Candidate) version at regular times: it
works, is feature complete, developers think it's stable, but others may
disagree.
D) When we think all problems are solved, we release a GA (General
Availibility) release.

To keep it simple I propose to keep FC the same as the last milestone
release.

Although we are planning to deploy this release management system for all
Pentaho projects (Reporting, Analyses, Platform, Data Integration, etc) we
would still welcome feedback on this.
I have to stress that we're trying to keep this as light and unrestrictive
as possible and that it's basically a method of communication with the
outside world.
Please keep Jay Meldrum, the Pentaho release manager in CC if you have
comments on the release process.

Also feel free to provide input for the 2.4.1 release schedule below. In
the 2.4.1 branch I think we can take advantage of the massive attention and
feedback we received over the last couple of weeks to get to a really stable
version.
I think it's fine to cool things down a bit and focus on ease of use and bug
fixing for a few months. I'm not seeing any urgently needed features that
are missing at the moment, let us know if you think otherwise.


2.4.1-M1 : Februari 19th (wad of bug fixes, db explorer enhancements,
limit size of log, mirroring partitioning method, ?)
2.4.1-M2 : March 5th (remote job execution, improve filing of bug
reports, ?)
2.4.1-RC1: March 19th
2.4.1: April 1st. (GA)

Have a great day!

Matt
____________________________________________
Matt Casters, Chief Data Integration
Pentaho, Open Source Business Intelligence
http://www.pentaho.org <http://www.pentaho.org/> -- mcasters (AT) pentaho (DOT) org
Tel. +32 (0) 486 97 29 37







--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "kettle-developers" group.
To post to this group, send email to kettle-developers (AT) googlegroups (DOT) com
To unsubscribe from this group, send email to kettle-developers-unsubscribe (AT) g...oups (DOT) com
For more options, visit this group at http://groups.google.com/group/kettle-developers?hl=en
-~----------~----~----~----~------~----~------~--~---