|
Rockbox mail archiveSubject: Re: Archos is dead; Long live ArchosRe: Archos is dead; Long live Archos
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 Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy |