From: Sam Kuper via rockbox-dev <rockbox-dev_at_cool.haxx.se>
Date: Sat, 25 Jul 2020 15:36:00 +0100

I haven't made any meaningful contributions to Rockbox repos, but I'd
like to contribute a couple of suggestions/replies here.


On Fri, Jul 24, 2020 at 01:51:36PM +0200, Sebastian Leonhardt wrote:
> [..] Is it possible to fork off something like a "legacy branch"? So
> if suddenly someone shows up who is interrested in the old archos he
> can easily commit new patches or backport stuff from the master brach.
> [..]

Pros:

- As Solomon pointed out in a different reply, branches (and tags) are
  lightweight in Git: they're (mostly) just pointers to a commit. This
  means it wouldn't be especially burdensome to have such a branch or
  tag. Some Git workflows (see below) do recommend this sort of thing
  for previous major releases.

Cons:

- As Solomon also pointed out elsewhere, there are arguments to be made
  for not cluttering (D)VCS repositories with additional
  tags/branches/etc just on the off-chance that someone might branch at
  that point in the future. After all, such a person would be able to
  create such a branch themselves if they wanted to.

My conclusion:

I'm slightly more inclined to the "Cons" side, but I don't think it
matters much either way. I think a better approach might be for Rockbox
to adopt a specified Git workflow (preferably an existing one; else a
new and documented one), as this would make it clear to current and
future developers what "the right thing to do" would be. If a workflow
is adopted, it should be noted in one or other of these files:

https://www.rockbox.org/wiki/UsingGit

https://git.rockbox.org/cgit/rockbox.git/tree/docs/CONTRIBUTING

  
What do I mean by a "Git workflow"? I mean something like: "a set of
conventions about when and why branches or tags should be created or (in
the case of branches) merged, and what they should be called." See
https://sampablokuper.github.io/update/2018/04/03/good-guides-to-git-and-git-hosts/#workflows
.

N.B. It is *very* hard for humans to design a Git workflow that
accounts for all eventualities; rather, they provide sensible heuristics
for common cases, to relieve developers of routine decision fatigue.
That allows cognitive resources to be conserved for the edge cases :)

> [..]
> Am 24.07.2020 um 01:04 schrieb Solomon Peachy:
>> I'm about to pull the trigger on a large patch series that (finally)
>> removes all support for the original devices Rockbox was created to
>> support;

That's a big deal! While it's sad to see some old devices retired
(although as you point out, they will continue to work with
existing/previous releases), it's also wonderful that you are
maintaining the code and infrastructure to provide the best support
possible for more recent devices. Thanks for all your efforts!


> [..] IMO we should acknowledge this by a new (major) version number
> (so, 4.0).

I support this proposal.

Per [Semantic Versioning 2.0](https://semver.org/spec/v2.0.0.html):

    Given a version number MAJOR.MINOR.PATCH, increment the:

    - MAJOR version when you make incompatible API changes,
    - MINOR version when you add functionality in a backwards compatible
      manner, and
    - PATCH version when you make backwards compatible bug fixes.

The removal of support for a whole class of devices does seem to meet
the criteria for a major version increment.

I realise that Rockbox does not currently use SemVer per se. So, I
guess I am advocating two things:

- It would be great if Rockbox adopts SemVer.
- Whether or not that happens, the version should probably be bumped for
  the new patchset.


> Also the whole codebase will change a lot by the patches, even without
> functional changes, so I think it's useful to have a clear crop mark
> like "3.x code vs. >=4.0 code".

I would advocate following SemVer on this front. So rather than
incrementing version based on e.g. the number of lines of code changed,
version increments should be based on what effect those changes have
(i.e. their meaning, which is what "semantic" refers to in "Semantic
Versioning").

> I wonder if we should take the opportunity and do additional code
> organising changes, like relocating files, reordering functions, etc.

I likewise suggest following SemVer on this.

On refactoring specifically, the SemVer spec is silent. Reasonable
people can (and do) disagree about whether or not to bump (increase) the
patch version in the case of refactoring, but consensus seems to
slightly favour bumping it. See:

https://github.com/semver/semver/issues/146

https://github.com/semver/semver/issues/215

and also:

https://github.com/semver/semver/issues/213

I personally favour using SemVer tags only on "releases", i.e. commits
from which binaries are built with the intention for end users to
download and install them. IMO, anyone using any other Git commit
should be doing so because they have some idea what they're doing.
Applying SemVer tags to those "in between" commits is superfluous
because they can already be uniquely identified by their commit hashes.
So, if the only difference between release A and subsequent release B is
that several refactoring commits happened in between, then I'd bump the
patch tag for release B.


Thanks again to Solomon & everyone who has developed/maintained Rockbox.

Sam

-- 
A: When it messes up the order in which people normally read text.
Q: When is top-posting a bad thing?
()  ASCII ribbon campaign. Please avoid HTML emails & proprietary
/\  file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.

Received on 2020-07-25