Ted, There's no formal process for contributing fixes and releasing yet, but some good practices should be followed.
Before checking in a relatively small change or sending in a small patch, I'd recommend testing against the examples in the code base, with both bundle=true and bundle=false. Test on Firefox, IE, and Safari (and Chrome?) if you have Windows, or Firefox and Safari if Mac. If you check in and then something breaks as noted by someone else, try to fix it as quickly as possible. We don't have a testing framework yet, so by "test" I meant just trying to play with the exhibit or timeline examples and see if anything breaks. Checking in a series of small changes is better than checking in a huge change in one shot. If you can't break a huge change into small ones because the change is quite fundamental, I'd suggest emailing this list before checking in just to give everyone a heads-up, or a chance to object the change and discuss it. As for releasing new versions, I think that should be voted by the community. If you branch, say for experimenting with a research idea, then you can do whatever you want with that branch. But when you're thinking about merging it back onto the trunk, then consider it a huge change. I've been told that branching is usually not a good idea, because too often the branch diverges significantly from the trunk, and merging it back is really hard. Of course, these practices that I just mentioned are also up for discussion. David Edward Benson wrote: > Larry (and/or David H), > > Is the preferred method of contributing fixes to just check them into > the head of the repo and announced what you have done? (Following the > commit message advice you sent out previously, of course) > > Or is there some more formal process of checking into a branch or > submitting a patch, etc. > > I have a performance enhancement that I'd like to check in for > Exhibit. It prevents re-calculating facet labels for collapsed list > facets (lazily doing the re-calc when they are uncollapsed instead). > > Thanks! > ted > > On Sep 23, 2008, at 6:17 PM, LarryK wrote: > > >> Hi Everybody, >> >> I've released Timeline v 2.2.0 >> >> New features from previous release >> Upgraded to include JQuery 1.2.6 (eob) >> >> Release notes >> http://code.google.com/p/simile-widgets/source/browse/timeline/tags/2.2.0/RELEASE_NOTES.txt >> >> Available now as zip files and from the svn >> timeline_source.zip -- complete sources including Jetty web server, >> examples and more >> >> http://code.google.com/p/simile-widgets/source/browse/timeline/tags/2.2.0/timeline_source.zip?r=1594 >> >> timeline_libraries.zip -- minimum js, css and image files needed >> >> http://code.google.com/p/simile-widgets/source/browse/timeline/tags/2.2.0/timeline_libraries.zip?r=1594 >> >> SVN access: >> http://code.google.com/p/simile-widgets/source/browse/timeline/tags/2.2.0/ >> >> Thanks to the contributors and testers. >> >> At this time, as far as I know, there will no public hosting site for >> this release. We hope to have one at some point. In the meantime, like >> 99% of other open source projects in the world, you can host the >> Javascript files yourself. The source includes a personal web server, >> or you can use any web server for your Mac, Windows or Linux machine. >> >> Please try out this release! Your testing makes a real difference. >> Comments appreciated. >> >> Regards, >> >> Larry Kluger >> New York City >> > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "SIMILE Widgets" 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/simile-widgets?hl=en -~----------~----~----~----~------~----~------~--~---
