release schedule proposal

[Inge Wallin]

On Wednesday, February 02, 2011 10:34:30 Pierre Stirnweiss wrote:
> On Wed, Feb 2, 2011 at 10:18 AM, Boudewijn Rempt <boud at valdyas.org> wrote:
> > On Wednesday 02 February 2011, Inge Wallin wrote:
> > > Do you plan to make real, i.e. not previews, of Krita in the mean time?
> > 
> > The
> > 
> > > reason I ask is that I wonder which Linux distros are going to package
> > 
> > the
> > 
> > > previews and how.
> > 
> > I think that (after a bit of cleanup), Calligra master contains a stable
> > version of Krita that is a big improvement over KOffice 2.3. So I would
> > want to communicate that to users. I think the same holds for the other
> > apps -- with 37 feature branches, we've clearly shown that we've grasped
> > the git way of working.
> 
> If I remember properly Oslo, we actually had planned to have a "always
> stable" master and features developed in branches that would be merged when
> "ready". Bug fixes should be done in master.
>  I think this is actually working pretty good as of now.
> 
> So would it be possible to have on a regular basis (monthly why not), a
> "stable snapshot". I am not sure there should be a link with a future
> "numbered" release (like 3.0 technology preview). That way we could have
> "numbered release" linked to evolution in the software rather than date
> constraint.
> 
> We could have the following then:
> - Calligra [last release number] Stable snapshot [YYMM]. These would
> provide both "maintenance releases" and new "finished " merged features.
> - Calligra [new release number]: when we decide we achieved technically a
> new Milestone.
> 
> Pierre

I may have misunderstood, but if I understood correctly I'm very sorry to have 
to say that I hate this. The reason is that it is a developer-centric way to 
work rather than a user-centric.

I'm sure it will be very ego-boosting for us developers to get new versions 
with new fancy features out there as soon as possible.

But as a user, I expect to be able to update to either a new version with new 
features and possibly also new bugs *or* a more stable release with no new 
features but also definitely less bugs.

If this is the way that we will do things, then the user will live in a state 
of perpetually changing set of bugs and more or less well-working new 
features.

For a short time, until we reach something like a big enough feature set that 
a real organization can use it, then perhaps this could be a way forward.  But 
I know that admins at larger installations prefer stability much before new 
features.  And stability is what will suffer with this scheme.