[Dnsmasq-discuss] Stable releases v. development releases.

[Ed W]

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