Re: New release time?

[Christopher Faylor <cgf at redhat dot com>]

On Thu, Apr 10, 2003 at 10:55:05AM +0200, Corinna Vinschen wrote:
>On Thu, Apr 10, 2003 at 01:32:32AM -0400, Christopher Faylor wrote:
>> On Thu, Apr 10, 2003 at 01:28:39AM -0400, Christopher Faylor wrote:
>> >Should we unleash 1.3.23 on the world?  This would be the first 64
>> >bit capable version of cygwin, right?  Are we fully ready for that?
>> 
>> To answer my question, one thing I'd really like is 64 bit inodes.
>> We don't have that now, right?
>
>No.  We could add them but that requires another newlib change due to
>the definition of ino_t.  Shall I?

I think it's worth it.  Does anyone know if 64 bit inodes will cause
trouble, though?

>AFAICS we're not fully ready for 1.3.23 even w/o 64bit inodes.
>
>There's that strange core dump of the latest ctags version (5.5) which
>only happens in the CVS version of Cygwin, not in 1.3.22, so we introduced
>a bug somewhere.  When the error happens, the stack is totally corrupted.
>I'm trying to track that down.
>
>Another problem is the 32/64 capability itself.  While no package
>maintainer is *forced* to rebuild his/her packages, that ideally happens
>quick.  Especially the packages handling users and groups are pretty
>important and that's a *lot* of packages.

Why does it matter if a package maintainer does things quickly or not?
Things will still work.  The answer just changes in the cygwin mailing
list from "It's not possible" to "The package maintainer needs to rebuild"

>As soon as we release 1.3.23, we should go ahead and rebuild all packages
>under control of at least people on this list within a week.  On
>cygwin-apps we should encourage all maintainers to rebuild as quick as
>possible and we should set a date (+6 months or so) after which all
>non-rebuilt packages are removed from the distro.  This has the
>interesting side effect that we can see which packages have lost their
>maintainers ;-)

I am sure a lot of packages are sans maintainer.  I agree that we should
ask people to rebuild but, again, I don't think it's urgent.

>Bottom line:  I think introducing 32/64 needs a bit of preparation.
>And btw., shouldn't that be 1.5.0?

I've asked this question a couple of times and never gotten a resounding
yes.  I've also talked about keeping two parallel lines of development
going but, AFAICT, there is no way that could work with the 64 bit stuff.
Once a package has been built for 1.5.0 it would stop working for 1.3.23.

However, I think I'll go bump the version to 1.5.0 now.  What the heck.

cgf