[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