On Sun, Aug 16, 2009 at 8:37 AM, Ben Smith
<[email protected]>wrote:

> ....
> I propose we identify the issues that we want fixed right away from
> the open issues list and from the fixes in 1.2dev and apply them to
> 1.1 maintenance to create a 1.1.4 release.  1.2 sounds like it needs a
> good amount of testing, and that'll take some time.  It seems to me
> like that would be an ideal time to migrate, as important issues will
> be addressed for general consumption.
>
> Yes, I'm volunteering.  And yes, I can be convinced to look at it
> other ways.


That sounds pretty good to me, if it's not too much work to migrate all the
bugfixes. I would point out a few things:

* PyWeek participants are an important part of the community of Pyglet
users, and due to PyWeek rules, we might want to wait until after it's over
(September 6th) before making any release, or we'd risk disqualifying Pyglet
for use in the current PyWeek. (Or it could be that a pure-bugfix release
would be ok... Richard? The rules require use of libraries that were
available and fully documented at the start of August, but a submission must
still work when used with the "latest version" of those libraries -- so
incompatible changes are certainly a problem.)

(At least one of the bugs that 1.1.4 would fix (timer crashes) is one that
caused trouble for quite a few PyWeek games last time, so it would be really
nice if the rules do permit releasing a 1.1.4 in time to be used for this
PyWeek... but taken strictly, I think they'd require judging the entries
using 1.1.3 even if 1.1.4 was out, unless Richard can be persuaded to do
something about that.)

* What 1.2 needs is more than just testing -- some documentation (at least
listing new undocumented APIs), and dealing with at least one old audio
feature that is no longer supported, and (perhaps, not sure) upgrading some
existing documentation and example code to work with it. (At least some code
in experimental has been broken by the changes; I don't know if anything
else has but it seems quite possible.) And in the community, a decision
about whether to split audio into a separate project so that each user can
choose whether the old or new version is better for them, independently of
the pyglet 1.1 vs 1.2 choice; and if yes, a bunch more work to do that. It
seems to me that the people doing that work should have the main say about
which VCS/DVCS would best facilitate it.

* It would be possible to have a "stable 1.1.4 release" and an "unstable
1.2.0 release" at the same time, or almost the same time. Then some of the
wider community of users would be helping with the testing of 1.2. So a
possible timeline would be to make both those releases from svn, then (if
the decision is made to do so) switch to Hg, then improve 1.2 (and its
documentation and examples) until it's "stable" and release it as 1.2.1.

- Bruce

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"pyglet-users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/pyglet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to