On Fri, Mar 12, 2010 at 10:21 AM, Dave Grijalva <[email protected]> wrote:
I've reset my master to what's in Pieter's. Since this is most inline with > the state of lighthouse, it's probably the best place to start. We should > probably re-evaluate what's scheduled for 0.8 since there's a lot of code > that's ready or near ready that doesn't necessarily line up with what's > scheduled. I have access to the lighthouse project now, so I can start to > work on this. > The current release is 0.7.1. Maybe we should map out a quick list of milestones to get us started? I propose we get a very minor update out that cherry picks any outstanding bug fixes from the network and call it 0.7.2. No new features or major refactorings. Then we start with Nathan's additions and work to get them reviewed/integrated for a 0.8 release. It would also be a good idea to limit the changes for 0.8 to things we can get done in a short period of time, say two weeks or so after the 0.7.2 update. 0.7.2 - new Sparkle feed - website redirection of the old Sparkle feed (so current users find us) - cherry picked bugs from the network - possibly run things through the static analyzer and fix any memory leaks 0.8 - add Sparkle delegate method to enable "cutting edge" releases - add completed/reviewed patches from Nathan's branch - anything else that comes up through further discussion that doesn't push back the release How does this sound to you guys? Getting the website moved over is important so we can remove the dependency > on Pieter to do releases through sparkle. > One thing that needs to be looked into here is getting the current Sparkle feed to redirect to the GitHub hosted version. This is important since it will allow existing users to find us without having to come back to the project to see what's new. Have you talked to Pieter about this? Pieter, would you be okay with this? I would also like to propose we run with two permanent branches in the main fork. The traditional "master" branch, which would contain all the code in the current stable release and a "beta" branch, where new patches would be applied. The thinking here is that all integration is done on the beta branch and once we're satisfied with the stability of it, we could merge that branch into the mainline. Beta releases could be generated from the beta branch after any given patch is merged. Final releases would come from the master branch whenever it's merged with the beta branch. Again, any thoughts on this process would be appreciated. Kevin
