[geeklog-devel] The road ahead - post 1.5.0

[Michael Jervis]

> I've said on more than one occassion that I think our release cycles are
> too long (1.5.0 was just an extreme case) and that I'd prefer something
> like 2 releases per year.

Maybe we should aim for 1 big release per year, with a plan to follow
that in quick succession with 1-3 minor releases with bug fixes and
minor new features.

> But are you sure we can pull this off? If this were a full-time project,
> I'd say sure, no problem. But we're all doing this in our spare time. We
> have jobs, family, other commitments and interests.

Well, depends what we do. What is involved in a release? If we do a
minor release in 5 weeks with bug fixes and community contribs that
are ready to go (debate what later). That's pretty do-able. Then we
plan to have a dead line for a 1.5.2/1.6 with the GSoC contributions
in. And aim for it with a plan instead of a "We want to release by",
but figure out what we need to do, how to do it and when it needs to
be done.

The problem is we are part time, but we don't try and deal with that.
We just drift. If we have a date to aim for and milestones on the way
we can track progress, manage expectations and change the plan, but we
should at least /have/ a plan to get the GSoC contributions out in a
timely fashion this year. And plan for the next timely releases.

> I can only see this working with some very, very strict restrictions on
> what and what not to add.

Well if we did that, the plan would be to have a cut off at a certain
date, so GSoC's big bits will be in by x, anything else by y, then a
plan to get that to a releaseable state. Then you just do the same. As
I said, we just drift.

Code freezes start when we can, not when they are planned to and
sometimes we break them. If we're a little more planned in advance,
then people who are working part-time round other commitments (all of
us?) know what's going on and won't accidentally delay the next
release by months because they start to commit parts of a big
development.

>>I think we should aim to have Geeklog 1.5.1 out by the end of July, it
>>should have a specific set of items in it.
> That would be 5 weeks then?

Yes, but, 1.5.1 is what 1.5.0-1 was in your email in my opinion.
Sub-version numbers work ok for urgent security releases, but 1.5.1 is
really the first bug fix release of 1.5 at least in my head.

> Not sure if the CTL is "ready to go". It may work as the hack that it
> is, but a proper integration requires more work, starting with an
> integration into the Configuration panel, the resulting DB and language
> file changes.

Ah yes, good points, but, maybe we can get Joe/whoever to crack that
off so that it can be rolled in with the GSoC then?

> Speaking of language file changes: There's also the issue of
> translations - those take time.

How quickly/readily do we get contributed translations? Do they
necessarily prevent a release? Can we provide language file updates
via Geeklog.net post-release?

Cheers,

Mike