If there are critical issues in the 1.1.4 branch, we can look at
fixing them in a 1.1.5 release.
Better, though, to move to 1.2 if the maintenance branch is working
well enough. Alex Holkner put together a summary of feature changes
here: http://groups.google.com/group/pyglet-users/msg/9733fab4436e635d
and the entire thread at
http://groups.google.com/group/pyglet-users/browse_thread/thread/700c63844ece86c2/e5b22b9d0c6320c4
is worth going over.
There are some other things that have occurred in the interim.
Unrelaible timing on Windows, and issues with 64-bit OSX 10.6, off the
top of my head. I feel that finding a way to make the testing system
more automatic would be nice, too, though there are very likely some
situations where tests must be inspected visually. I'd like to see
these things in 1.2, but that's just an opinion and I'm afraid I
haven't kept up with the developments on the OSX things.
Also, to open up a fun can of worms - now seems like a good time to
move to a dvcs, particularly Mercurial since google code supports it.
Are there compelling reasons to stick with SVN? I'd used git before
this discussion came up in August, and have been working with both git
and Mercurial since. A lot of the issue ports and backports would
have been easier with one of these, due to the overhead in tracking
down historical diffs to find out which things changed and when. I
would personally prefer working with hg over SVN.
Thanks,
-b
I'm afraid I haven't kept up with the developments on the OSX things.
Also, to open up a fun can of worms - now seems like a good time to
move to a dvcs, particularly Mercurial since google code supports it.
Also, an addendum to my first message on this thread, I found this
discussion of possible 1.2 features: http://code.google.com/p/pyglet/wiki/ReleaseSchedule
-b
On Jan 24, 10:49 am, Tristam MacDonald <swiftco...@gmail.com> wrote:
> On Sun, Jan 24, 2010 at 1:35 PM, Ben Smith
> <benjamin.coder.sm...@gmail.com>wrote:
As for 1.2 I think we should come up the minimum amount of work
necessary to get out a first alpha. I propose that anything Alex was
not confident in should be omitted from a first alpha to get it out
more quickly. There's probably a bunch of work in just testing and
verifying things. And I'm unsure what the state of the documentation
is.
I'm currently working on a game engine project that builds on top of
pyglet (and is intended to support pygame one day as well, but not
yet), so I have a vested interest in seeing development continue,
especially the OSX cocoa support. I also have access to machines
running 10.4, 10.5 and 10.6 so at a minimum I can help test. I'd be
interested in helping see it through, though I'm not well versed in
the Cocoa apis. I don't want to over-promise, but I can lend some
cycles. Tristam, if you could post a little summary on what works, is
considered done and what needs attention, I can see if there is
anything I can help with.
-Casey
> --
> You received this message because you are subscribed to the Google Groups "pyglet-users" group.
> To post to this group, send email to pyglet...@googlegroups.com.
> To unsubscribe from this group, send email to pyglet-users...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/pyglet-users?hl=en.
>
>
-Casey
-Casey
On Sun, Jan 24, 2010 at 11:56 AM, Ben Smith
<benjamin.c...@gmail.com> wrote:
> Also, to open up a fun can of worms - now seems like a good time to
> move to a dvcs, particularly Mercurial since google code supports it.
On a related note though not exactly development related, what is the
chance of moving the user contributions in the Pages of the Google
Group to a pyglet user wiki? Should one of us just start one or do the
devs have a plan to incorporate this with the pyglet website? (it
doesn't appropriate in the Google code wiki).
Ok. Is it correct to say that pyglet can still be used on OSX 10.6 64-
bit by some hoop-jumping?
I installed ActivePython over my Snow Leopard which solved a bunch of my issues, including being able to compile extensions like PIL...
Richard
I'd very much appreciate Mercurial <rollseyes>. If you do go to hg,
then please sign me up with push rights (or pull from my repo), I'd be
looking forward to get some, or any, tickets with patches I filed
closed.
I added a couple of pages to the google code wiki anyhow, since it's
already there.
http://code.google.com/p/pyglet/wiki/ProjectsUsingPyglet
http://code.google.com/p/pyglet/wiki/PygletCookbook
I agree that it would be good to integrate the groups pages. My main
constraint is time, I have a few hours here and there.
-b
On Jan 28, 11:50 am, Ben Smith <benjamin.coder.sm...@gmail.com> wrote:
> A separate wiki may be a good idea, the problem is contributors and
> maintenance.
>
> I added a couple of pages to the google code wiki anyhow, since it's
> already there.
Currently you need to be added to the pyglet dev list to edit the
Google code wiki, right? This makes sense, but probably isn't the best
for a pyglet user wiki in my opinion.
If no one objects, I'd be happy to set something up and migrate
resources from the pages/files here.
Yes, it also looks like one can add project contributers that don't
have repository write access but could edit the wiki, though.
>
> If no one objects, I'd be happy to set something up and migrate
> resources from the pages/files here.
This would also work.
-b
Also, to open up a fun can of worms - now seems like a good time to
move to a dvcs, particularly Mercurial since google code supports it.
Are there compelling reasons to stick with SVN? I'd used git before
this discussion came up in August, and have been working with both git
and Mercurial since. A lot of the issue ports and backports would
have been easier with one of these, due to the overhead in tracking
down historical diffs to find out which things changed and when. I
would personally prefer working with hg over SVN.
Mercurial (aka hg) and git are what I have some experience with, along
with SVN and CVS - so this is from that context.
Both hg and git are geared around branchy development with multiple
people doing commits. As soon as you clone a repository, you've got
the whole thing there on your disk. You can hop back and forth in the
project's history without talking with the server. You can clone it
from your disk again, without talking to the server. Since these are
local operations, they are very fast. With subversion, going through
history and changing branches requires server communication.
Since you've got the repository local, you can make changes and commit
them locally, then when you're satisfied with them, push them up to
the server all at once. This is also handy if you want to hack on
something but you're going to be offline - suppose you want to do a
few different things to the source code, fix a bug, add a feature. In
the SVN world, you'd end up with several files modified for different
reasons and have to cherry pick commits to make a coherent history.
With a local repository, you can commit each change in its context,
then push them to another repository with a coherent history for free.
One additional useful feature is that you can publish your repository,
either temporarily hosted from your machine in a trusted environment,
or set up something more secure for long term public hosting. This
way a maintainer could go through your repo and cherry pick the
patches they'd like to put in the main source archive, and they can do
this with full project history on both your end and their end. As
soon as they clone your repository, they have all the changes they
need locally and don't need to hit your repository again until they
want an update.
These tools allow for more flexible development workflows while at the
same time making it simpler and faster to branch and merge changes
from many sources.
And I'm not against SVN, it is an effective tool.
-b
On Jan 29, 10:13 am, Adam Bark <adam.jt...@gmail.com> wrote:
-b
On Jan 29, 5:16 pm, Adam Bark <adam.jt...@gmail.com> wrote:
Also I'd recommend http://hgbook.red-bean.com/read/ as well as
http://mercurial.selenic.com/wiki/Tutorial http://mercurial.selenic.com/wiki/UnderstandingMercurial
http://mercurial.selenic.com/wiki/QuickStart