Hi
A full split would mean extra work for you and probably more users
sticking to some stable branch for a long time. For dnsmasq I do not think
it is worth the effort.
If at some point during development, important fixes are necessary, it is
probably more convenient to open something like a temporary stable branch
with the sole purpose of applying fixes on top of the latest released
version.
OTOH if you were to give out a notice saying: here is something
critically important, please apply GIT commit xyz to fix it, that would
work just as well for our use case.
I was about to post a similar comment.
I don't see a point in splitting off stable branches constantly. But point
releases as needed if regressions are found sound about right.
IMO sounds good to me. A point release for regressions and
other bug fixes would be a good way of doing things instead
of another full on release which usually tries to mix in
feature changes as well pushing out a release.
That seems to be the concensus.
In the current state, I can simply do a 2.70 release to fix the nasty
bugs in 2.69, since there's been no feature work done since. In future,
if bugs come up later in the development cycle, I'll do point releases
to fix them.
With git there is no difference between tags and branches or whatever?
So what most people seem to do is roughly what you described above, but
in the interests of clarity:
- git checkout master
- fix bug/regression (assuming it exists in master)
- Git checkout <your tagged/branched release>
- git cherry-pick <relevant commits from master>
- merge, test, etc
- git tag new point release
The only subtlety above over common sense is that some hold the opinion
that all fixes should be in master first and then pulled into various
release branches
Also I presume it's obvious but you can always hop around and check out
any commit/tag/branch you like, mess around with it committing some
changes and then declare it a branch... As far as I understand a branch
is just a pointer to the tip of some set of commits, you don't need to
branch first and then start committing?
Obviously consistency of naming branches/tags helps with automated
stuff, but the rest is just a case of checking out the last release and
committing changes, you are simply putting a name on the tip of those
changes (and ideally the changes exist in master to prevent them getting
lost) but nothing else is special
These distributed VCS systems are very cool!
Ed W
_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
