On 9/25/05, Michael Schumacher <[EMAIL PROTECTED]> wrote:
> michael chang wrote:
> > On 9/23/05, Michael Schumacher <[EMAIL PROTECTED]> wrote:
> >>michael chang wrote:
> > The problem is that when the timeout dies, then should be a new
> > version; if there isn't one, it's kinda silly to have to re-install
> > the same version to extend the timeout.
> Reinstalling the same version wouldn't help, I'm talking about a hard
> timeout there - created when the release tarball is made, for example,
> and set to e.g. 60 or 90 days into the future.
What I mean is lets say the software times out after 70 days the
RC/beta is made. That means that there has to be a new RC/beta after
70 days, or otherwise no one can use it post those 70 days. If there
isn't, then someone might just rebuild the current RC for another 70
days, which is pointless.
E.g. if there was a 2.3.5 today, and it expires in 60 days. So that
means 2.3.6 has to be released within 60 days. How do we know 2.3.6
will be ready in 60 days?
If you want to force yourself on such a release cycle, by all means,
but last I checked, GIMP doesn't used fixed release cycles. I could
be wrong though; I'm not a GIMP developer. I mean, it's not like
fixed release cycles are all that bad of a thing. Then again, you
might want to give yourself some leeway (e.g. trying to release a
version of GIMP 15 days before the last RC/beta expired or something;
that way delays can be absorbed into the 15 days that remain from the
last RC/beta/devel release).
> > In that case, determining a timeout would be hard...
> Not really. Running development releases is only useful up to a certain
> time anyway - once current CVS has advanced considerably, there is not
> much to be gained from using an outdated one. Also, this should
> encourage people to keep the latest stable release installed - after
> all, this one will not time out.
Well, that's very true. I believe the 2.2.8 version of gimp is really
a 2.2.7+cvssomething on Debian - and those are offical packages.
> And finally, if anyone insists on using a development release longer
> than the timeout lets him, he can alwyys use the source and disable the
> timeout at compile time - and we can assume that if someone pops up with
> an outdated release he know what he's doing.
- Just my two cents
- No man is an island, and no man is unable.
Gimp-developer mailing list