future release roadmap

With 2.52.0 released, I will no longer pay attention to bug reports on
2.51, making exceptions to allow them to stay if I am pretty sure they
are likely still valid.

I have already qmerged a few minor changes past 2.52.0.

I anticipate releasing a 2.52.1, perhaps April 10.  That is just 4 weeks
after 2.52.0, to 1) allow enough time for people that update to find
serious problems, so that if we don't get bug reports by then, 2.52.0 is
declared ok and 2) to not got that long beyond 2.52.0 to start cleaning
up old ocaml and merging more disruptive changes.  I might do it at 3
weeks; I'm unlikely to do it sooner than that.

This means that people who don't update to 2.52.0 and later find and
report problems in their enivornement are going to be out of luck in
terms of having a fixed version of 2.52.x.

I do not want to cross into maintaining stable branches; the plan
instead is that each release is stable and there is no reason not to
upgrade.  If people choose to run old software and backport fixes, the
license gives them that freedom.  The checks from LTS distributions to
fund that process have not arrived :-) (That's a joke to make a point; I
don't want to do it even if paid.)

2.52.1 will include:

  fixes for any significant bugs found in the brave new world of 2.52.0,
  in which case any current idea of when 2.52.1 happens is invalid.

  minor bugfixes

  minor changes, as they arrive and seem sensible

  probably rototilling build instructions into BUILDING.md and removing
  from them the manual

  prbobaly some safe makefile cleanups, removing commented-out stuff and
  targets for pre-github UPenn release processes, etc.

Thus, 2.52.1 should be a safe update for all, and the version that
people who need a get-well plan from old ocaml will be pointed to as an
intermediate step.

Then, more disruptive changes are eligible for merging:

  Change minimum ocaml version, probably to 4.08.  Drop old versions
  from CI.  Merge PRs to remove compatibility for old versions.  (LTS
  people who want to use old stable software can use 2.52.1.)

  Rationalize names of binaries to unison and unison-gui.  Build unison
  always, and build unison-gui optionally (vs UISTYLE changing unison).

  More serious Makefile rationalization.

  Change lablgtk(2) to lablgtk3.  Ask for volunteers to fix windows CI
  if it's difficult, but if nobody wants to work on fixing it, I don't
  want to hold back from getting off of gtk2.  (I am guessing that
  lablgtk3 on Unix and Mac will not be that troublesome.)

  xattr? acl?

Then, it seems like time for 2.53.0.  No time frame, but I believe a
project should in general have a release no more than 6 months after the
previous.

Things probably beyond 2.53.0 (but really this and everything else
depends on having a PR that I cam comfortable with that is ready):

  Sync times by default


Greg

_______________________________________________
Unison-hackers mailing list
[email protected]
https://LISTS.SEAS.UPENN.EDU/mailman/listinfo/unison-hackers

-----BEGIN PGP SIGNATURE-----

iF0EARECAB0WIQS7wyAjWilQwVHG9Vsf2nroCY7WDgUCYi4r9gAKCRAf2nroCY7W
DoW1AJ9/0mD22DqdLkzitEmE/eqbQMq70ACdEgiEA5lr4VnnElsI1oqFp+loOv8=
=ML8n
-----END PGP SIGNATURE-----