[Development] Qt Commercial 4.7.5 is out - how shall we contribute is the best?
Oswald Buddenhagen
oswald.buddenhagen at nokia.com
Fri Jan 20 14:24:58 CET 2012
On Thu, Jan 19, 2012 at 06:58:40PM -0200, ext Thiago Macieira wrote:
> On Thursday, 19 de January de 2012 16.49.20, Thiago Macieira wrote:
> > So Digia is operating under special conditions right now, due to the
> > lack of Qt4 in Gerrit. Once it stabilises, I'd rather not see Digia
> > release a commercial version with a version number that the official
> > Qt doesn't have yet.
> >
> > That might imply they need a second version number. E.g.:
> >
> > Qt Commercial 4.7.5 update 1
> >
> > which indicates it's the Qt Commercial vendor branch, based on the
> > official Qt 4.7.5, but it's an update to something previously
> > released.
>
> By the way, considering what Ossi said in the other email ("4.7 is
> closed as far as the qt project is concerned [...] [because] fixes are
> not being applied to 4.7 first"), the Qt project needs to make a
> decision:
>
> - reopen the 4.7 branch and work on it, everyone, when a fix from
> someone (like Digia) turns up - tell Digia to stop increasing the
> version number - or turn over the maintenance of the 4.7 branch to
> Digia, including the ability to make releases
>
> My personal preference, seeing how busy everyone is with 5.0 alone,
> not to mention 4.8, is the third option. Turning over maintenance does
> not mean "anything goes", but it means Digia engineers and the rest of
> the community work on the 4.7 branch inside the Qt project. Commits
> should still be reviewed and a Qt project release should still happen.
> I'm sure there are Linux distribution packagers who can help in the
> release testing for their own maintenance updates.
>
> I propose we nominate a release maintainer/manager, who is responsible
> for setting the priorities for that release.
>
this doesn't address several issues i've already raised:
- who's going to review stuff? we already *know* that branch maintainers
cannot do the job properly. it must be the domain experts, but your
proposal is explicitly about freeing them from this duty. so what
about quality criteria (and the linked trademark question)?
- re-activating the branch would have some ugly implications on git: the
branch is cherry-picked (both ways, in fact). we can either merge it
back and get all those duplicated commits, or we can leave it unmerged
and thus "lose" the tags on it. the latter is the current state, and
is way easier to explain in the context of it being a vendor branch,
than if the branch and tags are retroactively promoted to "official"
status.
More information about the Development
mailing list