A new version of QuickSurveys should be released.
Follow the release process and then update the version number on the extension page.
Description
Description
Details
Details
Related Changes in Gerrit:
| Subject | Author | Repo | Branch | Lines +/- | |
|---|---|---|---|---|---|
| Release 1.1.0 | Jhobs | mediawiki/extensions/QuickSurveys | master | +15 -1 | |
| Release 1.0.0 | Jhobs | mediawiki/extensions/QuickSurveys | dev | +2 -1 |
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | • jhobs | T119757 Release next version of QuickSurveys | |||
| Resolved | • bmansurov | T119152 Spike: [2 hours] QuickSurvey schema did not create a table in log database from first survey | |||
| Resolved | Jdlrobson | T119367 Validate and handle a survey's platform |
Event Timeline
Comment Actions
There's no reason this shouldn't be the first major (1.0.0) release IMO. We've already run several surveys in production on our largest project.
Comment Actions
What will be in the next release? How should it be versioned? Seems like a minor release so far.
Comment Actions
@bmansurov @phuedx are you okay with bumping to 1 or should this be 0.7? Given tweaks are minor I'd personally rather hold out for a 1.0.0 release when we've run a few more surveys.
Comment Actions
I agree with @jhobs here. We've run a number of surveys in production on our largest project. 1.0.0 it is. We should also probably update the release status of the extension on the extension page.
Comment Actions
I also agree with @jhobs. To quote semver specification (points 4 and 5):
Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.
Version 1.0.0 defines the public API. The way in which the version number is incremented after this release is dependent on this public API and how it changes.
Comment Actions
I guess this is where my mindset is different... I saw the two surveys we ran as beta testing.
It still feels anything but stable to me and given the lingering bugs around ease of use, T119367, T115485.
That said I guess we can aim for a 2.0.0 release for those.
If the main motivation is we've already run surveys in production, to avoid confusion it feels like we should just reset the version number and do a release afterwards with the minor changes (it's already confused @Florian)
Up to you guys what you want to do here, don't feel strongly either way.
Comment Actions
This seems like a fine middle-ground to me. Basically the 1.0.0 release includes nothing (as a catch-up) and then a 1.1.0 immediately after with the current patches?
Comment Actions
Yup! I think that avoids all this confusion and why Florian and I were originally confused.
Comment Actions
Change 260680 abandoned by Jhobs:
Release 1.0.0
Reason:
See https://gerrit.wikimedia.org/r/#/c/259860/
Comment Actions
We couldn't do the 1.0.0 blank release due to a couple cherry-picked commits. Instead, I've changed the next release to 1.1.0 and clarified in the commit message why. The only thing I'm uncertain of is if I should rename 0.6.0 to 1.0.0 in the HISTORY file -- since that's effectively what we wanted to do -- or if I should leave it since nobody would be able to find a "Release 1.0.0" commit.