Re: time for a new release?

[Lane R. <la...@if...>]

on Sun, Jan 23, 2005 Joseph J. Strout may have said:

>I may need to ship my product with my own custom builds of Quesa, 
>then.  Any suggestions on how I should identify it?  It's after 
>1.6d19, but prior to what will presumably be 1.6d20...  Should I call 
>it 1.6d19b, perhaps?

How about 1.6d20...

>For that matter, if I find that 1.6d19 will work, are there official 
>builds of that available? 
><http://sourceforge.net/project/showfiles.php?group_id=45158> seems 
>to have built SDKs for 1.6d18, but for 1.6d19, it has only source 
>code tarballs.  Theoretically I can build one that comes out exactly 
>the same as anybody else's build, but in reality, that's not always 
>the case.  So, is there an official build somewhere I'm missing, or 
>should I just build my own and bill it as 1.6d19?

...since such a major change should really move the version # up to 1.7
whatever.


My suggestion: the Jan 1, 2005 is 1.6d20, your version is 1.6d21, and a
merge of the two is the official 1.6 release. Bugs and all. (or maybe
have a beta if you want, but make it short and make sure to have a final
1.6 release.)

Then start the current CVS branch as 1.7 and move forward.

Really, I think the project needs to move past the 1.6 roadblock in
versioning, as well as the "development" status; you need beta releases
and final releases and don't need to keep worrying about keeping the
version set at the last QD3D version # ... from the outside it just makes
it seem as if the project has died or is moving too slowly to bother
with. (And maybe 5 people remember why the version # is 1.6 anyway.)

mho of course :)

Lane Roathe
President          Ideas From the Deep        <http://www.ifd.com>
___________________________________________________________________
Data, data everywhere . . . and not a thought to to be had.