Re: Time for a release?
Manoj Srivastava <srivasta@debian.org> writes:
> Now, in this specific case, since there has been only one commit
> to the bug####-rra branches each, this is not an issue -- I can just
> look at the commit. But if you ever add another change to any of these
> branches, one would have to do
> git diff bb27c26983818b9fd4ee8bcca705c0381c47010a bug172436-rra
> to see what changed.
>
> I also note that master seems to have the change present on the
> branch bug367984-rra; but it is not obvious that it came from
> bug367984-rra (well, the commit message subject is the same, but ..).
> Perhaps this merge --squash is not a good idea; I think it is nicer to
> see gitk --all display the merge even if we get to see _all_ the
> history. What do you think?
I would be very happy to just merge everything all the time. I don't
really understand the Git dislike of that workflow; merging everything
captures all of the history and also lets us delete old branches (like
bug367984-rra) without Git complaining that the changes haven't been
merged.
If that sounds good, I'll merge from master into all the pending bug
branches and change the wiki to suggest a simple merge onto master when a
bug is finalized.
I suppose the primary objection is that it makes for a messy branch
history, but with Policy I expect to be deleting the branches once they're
merged anyway, so I don't think that applies.
>> Should we call this upcoming version 3.8.0.0? I think it has enough
>> substantial changes to warrant the larger version bump.
>
> Sounds good to me.
I'll make that change in the repository.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: