<div dir="ltr">OK. <div><br></div><div style>If you throw a few notes somewhere/anywhere about this (very brief is fine---just so it isn't encoded only in this thread) so I can come back to it (or you can point me at it when I do the wrong thing), that would be great.</div>
<div style><br></div><div style>Cheers,</div><div style>Matt</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Apr 24, 2013 at 9:06 AM, Martin Ellis <span dir="ltr"><<a href="mailto:ellism88@gmail.com" target="_blank">ellism88@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote"><div class="im">On Wed, Apr 24, 2013 at 1:27 PM, Matt Jadud <span dir="ltr"><<a href="mailto:matt@jadud.com" target="_blank">matt@jadud.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In terms of branching and releasing: back-merging anything sounds like work.</blockquote><div><br></div></div><div>It is usually easy (thanks to git), as you can just cherry-pick bug fixes into the branch.</div><div>
We can also make it easier by making sure our commits are fine enough grained, and only working on small bits of code at once. </div><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Unless we can justify the time, how about if we just tag at stable points. Declare major revision updates when a big feature comes in. Otherwise, let the past in the repos be the past? (Or, if you prefer, give me a good reason why the back porting matters? I don't see one, but I'll admit that I haven't thought about it.)</blockquote>
</div></div><div class="gmail_extra"><br></div>It may not be necessary, but lets us maintain a stable branch, that does not have non-backwards compatible changes in it.<br></div><div class="gmail_extra">This way people who are using and not developing can be happy that new minor releases are just bug fixes and will not effect their code.</div>
<div class="gmail_extra">Think python 2 V 3.</div><div class="gmail_extra">It is extra work, but it will give people more confidence in the code.</div><div class="gmail_extra">I have used this model for projects with only a handful of developers and it works well, and fits well into the code review/pull system.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">--</div><div class="gmail_extra">M</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div></div>
</blockquote></div><br></div>