Mail Archives: cygwin-developers/2003/03/19/16:19:42
Corinna has suggested to me that maybe we should be bumping the cygwin
version to 1.5.0 given the 64 bit changes and my upcoming device
handling and mount table changes.
I'm thinking that we might need a few more 1.3.x releases before 1.5.x
is stable so *maybe* I could keep 1.5.x cygwin releases in the "test"
category for a while and keep releasing 1.3.x until things settle down
there.
It may be that there will be no need for further 1.3.x versions but I
had sort of hoped to have a gold version of 1.3.x ready that people could
rely on before we started really destabilizing things for 1.5.x.
I know that we'd talked about changing to version 2 of cygwin, too, but
that is going to be a pretty daunting task. It means someone amongst us
would have to write a cygwin1 wrapper DLL so as to not leave the old
cygwin1 users behind. It ideally means rebuilding the whole
distribution with cygwin2 libraries. It means stripping out all of the
legacy code in cygwin1.dll (rewarding as that would be).
So, I think we can stick with 1.5.x for the conceivable future.
Of course, to get the full benefit of the 64 bit stuff, maintainers will
have to start rebuilding with the 64 bit version of the dll, too, so
part of the above is inevitable anyway. And, as soon as someone rebuilds
their app with 1.5.x, it will no longer be backwards compatible with
1.3.x. Maybe that means that 1.5.x should be released sooner rather than
later. Head hurts.
Another idea I had was to throw out the "odd releases net, even releases
Red Hat" versioning that DJ and I came up with so long ago and just bump
the version to 1.9.0, working for the eventual transition to a
cygwin2.dll. When we feel comfortable that everything is ready (dll wrapper,
legacy code stripped) then we roll the version to 2.0.0 and then start
actively rebuilding everything for the new DLL.
Anyway, I'm leaning towards a 1.5.0 bump soon but I reserve the right to
go with the 1.9.0 too, at some point.
cgf
- Raw text -