search

PiRogueToolSuite / deb-packages

PiRogue Debian packages
https://pts-project.org/
GNU General Public License v3.0
2 stars 2 forks source link

Decide on branch management and version numbers for Debian 12 #15

Closed CyrilBrulebois closed 1 year ago

CyrilBrulebois commented 1 year ago

Branch management

At the moment, we have a main branch where all development efforts go, and we're releasing packages that target a Debian 11 base (be it Raspberry OS or official Debian).

With the upcoming “porting to Debian 12” efforts, we should probably fork main into a separate branch. An easy way to deal with it would be to use the Debian codename i.e. bookworm but this could be a little weird (not everybody knows how Debian 12's being Bookworm, or the other way round). Maybe debian-12 would be clearer?

In any case, once everything has been ported, and once the Debian 11 to Debian 12 upgrade path has been verified (possibly releasing a few more packages for Debian 11, to ease the upgrade path to Debian 12), main would have served its purpose and could disappear. We would then have to switch the default branch in GitHub, and that might be confusing for casual developers.

Another way to deal with it could be to work current main into bullseye (or debian-11). Developers who want to update packages for Bullseye/Debian 11 could do so in that branch, and the porting efforts would go directly into main. After a while, debian-11 would become stale (and that's OK), until main starts being used to port to Debian 12, and we fork bookworm (or debian-12) until the Debian 13 base is fully ready and can be upgraded to.

Version numbers

To ensure there can't be any clashes between packages released from either branch (which are going to evolve in parallel until the migration is fully ready), an easy way is to agree on constraints on version numbers, e.g. using 1.x versions for the current base, 2.x for the next one. This might be a big jump for the PTS project, and maybe we should just have some 1.x to 1.(x+1) bump everywhere in the “new” branch (cf. above), while the “old” branch would only get 1.x.y to 1.x.(y+1) updates?

Consistency

To make sure we don't end up reusing package version numbers, it might make sense to have some check on both PPAs (same version forbidden unless packages are exactly the same — i.e. bit-for-bit, which could happen if we initialize the new PPA with a copy of old packages until all of them are updated — and checking the new PPA only has higher versions than the old PPA's ones). Such a check would of course depend on the decision regarding the user-facing layout and the underlying repository layout (single repository would be easier, multiple repositories a little less so). We could even think of a pre-commit hook to be on the extra safe side.

CyrilBrulebois commented 1 year ago

Alright, the plan regarding branches is as follows:

The plan for versions, assuming they match MAJOR.MINOR.PATCH:

This ensures we can still publish updated packages from both branches, that don't clash, and that don't prevent upgrading (having all versions in main lower than versions in debian-12).

I'll prepare that in the next few hours.

CyrilBrulebois commented 1 year ago

I think we're all done, for deb-packages but also in other repositories. At least the list of binaries in the pirogue/ directory of the PPA looks like everything was covered here. Closing accordingly.