<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">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 style>It is usually easy (thanks to git), as you can just cherry-pick bug fixes into the branch.</div><div style>
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> </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 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" style>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" style>Think python 2 V 3.</div><div class="gmail_extra" style>It is extra work, but it will give people more confidence in the code.</div><div class="gmail_extra" style>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" style><br></div><div class="gmail_extra" style>--</div><div class="gmail_extra" style>M</div><div class="gmail_extra" style><br></div><div class="gmail_extra" style><br></div></div>