03.05.2017, 17:27, "Sergio Martins" <[email protected]>: > On 2017-05-03 15:02, Konstantin Tokarev wrote: >> Remaining question is versioning. While it's fine to dub current >> release "5.9" (but not 5.0, because we will have another WebKit update >> in 5.10 time frame), using Qt versions in QtWebKit has downsides: >> >> 1. It is not clear if 5.N+1 ships with the same WebKit branch as 5.N, >> or is updated >> 2. It makes people believe that QtWebKit 5.N should be used with Qt >> 5.N only. QtWebKit supports wide range of Qt versions (starting from >> 5.2 as of now), and can be used e.g. as security update in Linux >> distro that does not normally update Qt version during its life cycle. >> >> Any comments? > > If Qt and QtWebKit will have different release schedules then that > numbering would indeed confuse people.
What about choice of new versioning scheme? I'm leaning towards "6.0.0" number, because it's larger than any 5.x and makes it clear that versioning is different now. Bug fixes will increment patch version (6.0.x), WebKit updates minor version (6.1.x etc), API/ABI breaking changes - major verison (7.0 etc.) Qt5 supermodule will be tracking latest available stable branch. When release branch is created (e.g. 5.10.0), corresponding patch release branch is created in qtwebkit repo (e.g., 6.1.1) and is frozen following the same schedule as Qt release branches. However, I'm not sure about two things: 1) Is it possible to have custom branch names in qtwebkit repository, or there need to be virtual 5.10 etc. branches to match other modules? 2) What about bug tracking in JIRA? I would like to keep existing issues as is, but assing new release numbers to items fixed in new releases ------------------------ Rationale why using Qt version is not optimal anymore: 1. New QtWebKit is using stable branch of WebKitGTK to simplify maintenance, and plan is to continue doing this in future. Currenly WebKitGTK creates new stable branch twice a year and follows GNOME release schedule. While this more or less matches Qt release schedule, there may be unfortunate cases when schedules mismatch, and WebKit upgrade won't be possible in time. Keeping WebKit not upgraded increases maintenance burden, because it's harder to cherry-pick patches from diverging trunk, and it's not possible anymore to reuse backporting work of WebKitGTK team. In case WebKit upgrade is finished before Qt release, it's highly desirable to allow downstreams (e.g. Linux distros) to get newer version faster. In case WebKit upgrade was skipped for some reason when new Qt release is made, it's important to reflect this in version number as well 2. There may be schedule missses because of lacking man power in QtWebKit team. Like now for example, release is long overdue and it's just unacceptable to hold it for more than half of year again. 3. As I already mentioned in the starting message, surprisingly large number of people believe that QtWebKit x.y is tied to Qt x.y, while it supports a range of Qt versions, and can be used as security update in Linux distros that do not normally update Qt version during their release life cycle. Historically, QtWebKit always supported at least N-1 release of Qt, and versioning scheme used in Qt 4 times since Qt 4.7 (QtWebKit 2.0 - 2.3) better reflected this fact. > > Have you thought about an LTS version too ? What would LTS mean, for > QtWebKit ? I think during the LTS lifetime we would still need to update > the inner WebKit, for security reasons, (that even happened for > QtWebEngine in a 5.6.x patch release). > > Thanks for your efforts on this! > > Regards, > -- > Sérgio Martins | [email protected] | Senior Software Engineer > Klarälvdalens Datakonsult AB, a KDAB Group company > Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) > KDAB - The Qt, C++ and OpenGL Experts -- Regards, Konstantin _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
