[geeklog-devel] The road ahead - post 1.5.0

[Dirk Haun]

Michael Jervis wrote:

>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.

Sounds good to me. If we may be so bold as to assume that we get into
GSoC again, we may want to sync the major release with that then.


>The problem is we are part time, but we don't try and deal with that.
>We just drift.

Yep.


>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.

For starters, we should start using the bugtracker more. Mantis has a
few features that we may want to use, e.g. subprojects, custom fields,
and filters.

Ideally, you should be able to see, at a glance, what is being worked on
for the next release. That should be doable with proper tagging and
defining a filter for it.


>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.

One problem with this: So far, our stance was that we would be
supporting the last two versions (current and previous release), and
that was usually easy to understand from the version numbers.

If there's, say, a 1.5.2 in December, we probably don't want to drop
support for 1.5.0 already by then. But providing, say, a security fix
for 3 versions would mean having to provide at least 4 tarballs (fix for
each version + a new complete tarball, plus possibly up to another 3
"combo" updates, in case there were earlier security fixes). That's way
too much to handle.

Of course, if we go forward in smaller steps, our users may be less
reluctant to upgrading ...


>How quickly/readily do we get contributed translations?

Depends. Some are very fast, others are only updated every other release.


>Do they necessarily prevent a release?

Depends, again. If there's a new feature with a user interface, we
should at least give the translators a chance.


>Can we provide language file updates
>via Geeklog.net post-release?

Sure - look at our download section. It tends to get cluttered up,
though, and some people may miss them.

bye, Dirk


-- 
http://www.haun-online.de/
http://geeklog.info/