Gale Andrews wrote:
> | From Vaughan Johnson <
vaughan@...>
> | Fri, 09 May 2008 11:42:20 -0700
> | Subject: [Audacity-devel] 1.3.6 schedule
>
>>> Re LRN's comment, am I still right thinking the "kick tyres" betas
>>> during GSoC coding are essentially internal, i.e. not up on the
>>> main website? That was my inference.
>>>
>>>
>> We haven't discussed that explicitly here, but probably so. I don't see
>> posting them as a problem, but we should probably keep 1.3.5 up, even
>> after 1.3.6, because 1.3.6 will be substantial different, therefore less
>> tested than the latest few 1.3.x versions. We can designate 1.3.5 as
>> "semi-stable"?...
>>
>
> Just my 2 cents.
>
> A disadvantage of suggesting greater stability of 1.3.5 vs. 1.3.6
> (either by giving different nomenclature or keeping 1.3.5 and 1.3.6
> prominently alongside each other as "alternatives") may be that
> we get less feedback about 1.3.6, which we really do need. Maybe
> we could limit ourselves to 1.3.5 being an "optional download"
> on each platform's download page?
>
> If we suspect the GSoC builds will be less stable than
> "1.3.6 from end of May" (likely?), then I doubt we should post
> those on the download pages of the main site. We could do so
> perhaps on the developers pages of the main site and Wiki?
>
> Why not go with LRN's idea of "alpha", which suggests potential lesser
> stability compared to beta? If we want to name 1.3.6 differently to
> 1.3.5 then "end of May" is 1.3.6 alpha1 and GSoc builds 1.3.6
> alpha2....n. If "end of May" is called 1.3.6 Beta then should the
> GSoC builds be 1.3.7alpha1....n?
>
>
I think 1.3.6 is likely to be less stable, and certainly less internally
tested (because of the switch in build type) than prior 1.3.x. And I
don't think we'd need a lot of feedback on modular build until after
GSoC. So, overall, I like the idea that the end-of-May release is
1.3.6a1 and the others during GSoC designated as 1.3.6a<n>. "Alpha"
traditionally meant "for internal distribution only, but with OSS, might
as well be open and post them as well, but keep 1.3.5 as the latest "beta".
(There's no need to spell out alpha -- one of the many traditional
version naming conventions is just two numbers and a possible suffix,
e.g., 1.4a1, 1.4a2, 1.4a3, ..., 1.4b1, 1.4b2, ..., 1.4c1 (for release
Candidate), 1.4c2, ..., then 1.4 with no suffix for the stable release.
We've so far been adhering to the *nix convention that betas have the
2nd number, "release", as odd, but I think we loosely agreed to move
away from that, because most users find it confusing, or at least not
illuminating, vs suffixes.)
In the meantime, I changed Audacity.h to make the suffix "-alpha_<date>"
(which I think is too long), but we might consider "a_<date>" rather
than incrementing numbers, both because we wouldn't have to increment
the number manually for each one (date from __TDATE__ automatically),
and we won't have to check the date stamp on the EXE or the About box to
see when it was built.
Thanks,
Vaughan
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone_______________________________________________
Audacity-devel mailing list
Audacity-devel@...
https://lists.sourceforge.net/lists/listinfo/audacity-devel
