[Development] Branching for Qt 5 repositories
d3fault
d3faultdotxbe at gmail.com
Fri Sep 28 14:51:21 CEST 2012
"stable" and "release" are too similar in meaning and might cause
confusion. Debian's naming scheme: unstable(or dev is
fine)/testing/stable is easier to understand at a glance. KISS
Keeping the word "master" out is a good idea though... since it's what
git defaults to and doesn't really tell you anything.
The word "next" is ambiguous. Seeing as "stable" (or what Thiago's
first post referred to as "Release") is "current", it's easy to get
confused and think "next" might mean testing (the middle one!).
dev/testing/stable is difficult to get wrong.
re: clone gets stable/release by default
shouldn't it be discouraged to change downstream since it just means
more work with merging back upstream? if they're fixing bugs, maybe
upstream already has a fix. or a fix might conflict with another fix
only in upstream. there are lots of reasons why we shouldn't encourage
working on a downstream branch.
For the "default clone", why not just NOT default to any of the 3
branches and present them with a selection? Again, just like Debian
does. Three different repos/branches and it won't be hard for the
developer to decide which repo they want to work with.
I think keeping all changes in the dev branch and then selectively
pushing them downstream based on severity (or simply non-destabilizing
factor) is a better approach than the multiple direction merging. For
example, the high priority SSL fix would have been in dev for only a
few minutes before being merged into testing and then stable.
re: Joao's 3-branch post from a while ago: His naming scheme etc is
fine, but I don't see the point in keeping releases synchronized with
the position of the earth relative to the sun. That's a pointless
growing trend among Linux distributions, and I think a project such as
Qt should remain requirements based. "When it's done".
Thiago:
>If this person developing the new fix comes up with a fix that is acceptable for the stable branch, then it makes sense to accept it, in spite of a different fix existing in dev.
Sorry, WHAT? Duplicating efforts is OK??? While we're at it we might
as well not re-use code either.
>Qt is big, but it's not hard to pay attention to the areas one is developing on.
But you shouldn't have to outside of the branch you're working on (dev
imo). Not only does someone working on stable directly have to watch
dev/testing, but someone working on dev now has to watch
testing/stable for changes too?? Doesn't sound worth it.
d3fault
More information about the Development
mailing list