On Sat, Aug 15, 2009 at 4:22 AM, Tristam MacDonald <[email protected]>wrote:

> ....
> It sounds to me as if we should focus our efforts on bringing trunk up to a
> full release, and put 1.2dev on hold for the immediate future.
>

Alex: thanks very much for your status description, that's just what we
need.

Tristam: To clarify a possible misunderstanding: AFAIK, trunk and 1.2dev are
the same thing, in the svn repository. That is, the most recent releases
have been made from

http://pyglet.googlecode.com/svn/branches/pyglet-1.1-maintenance/

but new features and refactoring intended for "development towards 1.2" (as
well as many bugfixes) have been done only in the trunk, i.e. in

http://pyglet.googlecode.com/svn/trunk/

since there is no separate (non-trunk) branch corresponding to 1.2dev. This
means that "bring trunk to a full release, but put 1.2dev on hold" is not so
simple, since trunk and 1.2dev are two names for the same "branch".

Alex, is my understanding correct?

If it is, then making a release from trunk will require either reverting
some work (after copying it into a new separate 1.2dev branch) (figuring out
exactly what to revert might be a lot of work and introduce new bugs), or
finishing some work (especially in audio, based on Alex's summary), or
accepting the possibility of a new release worsening behavior (especially in
audio on Windows). (And accepting some loss of audio functionality in any
case.) The latter choice (just release, and accept that some old behavior
will have new bugs) is easiest, and might be acceptable -- I don't know.

Another possibility is to copy trunk to a new 1.2dev branch, revert trunk to
1.1-maintenance, and backport some bugfixes from the new 1.2dev branch to
the new trunk. This is more conservative, but risks relegating a lot of good
work in 1.2dev to the back burner for too long.

My sense is that cleaning all this up is unavoidably a significant amount of
work, no matter how it's done, so the decision of what strategy to follow
should be influenced greatly by whoever steps up to actually do that work
(starting with reading the current code to fact-check and update Alex's
summary).

Also it will be necessary to warn users that the next release might well
break things that worked before.

--~--~---------~--~----~------------~-------~--~----~
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