[geeklog-devel] The road ahead - post 1.5.0

[Michael Jervis]

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

OK so do we want to start figuring out which bugs are critical for
1.5.[1|0-1] using Mantis and assigning them a status that indicates
such and assigning them out?

Should we then start using Mantis to create a sub-project for
1.5.[2|1] with feature requests (or whatever mantis has) to indicate
what we should be building for it? Moving bugs we don't plan to fix in
1.5.[1|0-1] into fix for that if they are too big or whatever?


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

Do we reserve version numbers for that then? 1.5.0 has fixes 1.5.1,
1.5.2 etc and the next release is 1.6? Since geeklog2 is now aptitude,
can we decide when gl1 gets to be GL2? Or does it?

if we release 1.5.0-1 as a bug fix only release, and we have a
security issue, do we have to do 1.5.0sr1 and 1.5.0-1sr1?


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

There's always that...

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

So we could identify "must have" translations where we have a reliable
fast translator (such as German ;-)) and make sure the translator
knows the road-map in advance and can have plenty of warning as we get
ready and thus having the translations will be manageable.

Anyone else want to chime in? Sounds workable to me...