Sounds perfect. There's currently a 'master' branch and a 'stable'
branch. I'm a fan of this workflow vs using 'master' as 'stable'.
This is basically the same as you've proposed only with a minor naming
difference. Plus, it's the way pieter was already doing it. As
always, it's best if contributors work in topic branches.
There are already a few commits on top of the last release in the
stable branch, so that's go good jumping off point for 0.7.2. We can
pull fixes into there and get something out soon. If anybody has
bugfix commits out there, please bring them to my attention as soon as
possible so we can get them in.
Meanwhile, I'm going to merge the stable branch down into master and
try to consolidate it with the pretty large set of changes that were
applied there after 0.7.0. Then we can start putting the two releases
together at the same time.
I haven't talked with pieter yet about moving the website, but I will
send him an email tonight. If he wants to continue to host the site,
that would make my life easier, but I have the impression he wants to
remove himself as a bottleneck from the project.
-dave
On Mar 11, 2010, at 9:05 PM, Kevin LaCoste wrote:
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
