Bump stable10 to 10.2.0

[phil-davis]

Description

Bump the version in stable10 from 10.1 to 10.2 prealpha

Related Issue

Reasons to bump the minor version include:
#34492 "Add confirm password after new password" has provided a new feature (not just a bug fix)
#34280 "Backport of Increase size of login_name from 64 to 255" has a database migration

I guess there might be other things that are not just bugfixes to 10.1.0

Motivation and Context

Reflect the truth of what is in stable10 that has been merged since 10.1 was released.

There are some new acceptance tests in stable10 that do not work on 10.1-release. We need to skip those for at least 10.1.0, so we need to bump the version anyway.

How Has This Been Tested?

CI

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Database schema changes (next release will require increase of minor version instead of patch)
• Breaking change (fix or feature that would cause existing functionality to change)
• Technical debt
• Tests only (no source changes)

Checklist:

• Code changes
• Unit tests added
• Acceptance tests added
• Documentation ticket raised:

Open tasks:

• Backport (if applicable set "backport-request" label and remove when the backport was done)

[codecov]

Codecov Report

Merging #34534 into stable10 will not change coverage.
The diff coverage is 100%.

@@             Coverage Diff             @@
##             stable10   #34534   +/-   ##
===========================================
  Coverage          64%      64%           
  Complexity      19247    19247           
===========================================
  Files            1276     1276           
  Lines           75801    75801           
  Branches         1291     1291           
===========================================
  Hits            48515    48515           
  Misses          26907    26907           
  Partials          379      379

Flag	Coverage Δ	Complexity Δ
#javascript	53.22% <ø> (ø)	0 <ø> (ø)	⬇️
#phpunit	65.15% <100%> (ø)	19247 <0> (ø)	⬇️

Impacted Files	Coverage Δ	Complexity Δ
version.php	100% <100%> (ø)	0 <0> (ø)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 678ca0d...5b6017b. Read the comment docs.

[PVince81]

this would qualify as a process change. usually we only increase the version at the time we do the release, see https://github.com/owncloud/administration-internal/tree/master/release-scripts#b---increase-version-number-in-version-file

to reconsider this, we need to make sure that this won't cause other side effects

cc @DeepDiver1975

[PVince81]

@phil-davis should we setup a discussion to discuss the requirements of QA in regards to fixed version numbers and examine alternatives ?

[phil-davis]

@phil-davis should we setup a discussion to discuss the requirements of QA in regards to fixed version numbers and examine alternatives ?

@PVince81 I am happy to discuss anything ;) IMO the thing to do is to bump the version number in a branch (e.g. stable10) as PRs are merged that would require the corresponding semver version change.

For example (starting from a future imaginary 10.4)

• after 10.4.0 release, the first PR is merged and is just a bug fix - bump the version to 10.4.1.0
• a PR is merged that provides a new feature(s) - bump the version to 10.5.0.0
• a PR is merged that has a backward-compatibility break - bump the version to 11.0.0 (and of course pressing the merge button on such a PR requires thought and planning, and adding a stable11 branch and...)

[PVince81]

now thinking of it, I don't see any strong objections for not bumping the version.

after all, if we'd choose to do an alpha or beta tarball release we'd need to bump the version anyway and I wouldn't use a release branch for those (at least not for now with the old branching model)

[PVince81]

👍