From gdt at lexort.com Sun Mar 13 13:37:58 2022 From: gdt at lexort.com (Greg Troxel) Date: Sun, 13 Mar 2022 13:37:58 -0400 Subject: [Unison-hackers] future release roadmap Message-ID: 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From toivol at gmail.com Tue Mar 15 04:20:02 2022 From: toivol at gmail.com (=?UTF-8?B?VMO1aXZvIExlZWRqw6Rydg==?=) Date: Tue, 15 Mar 2022 09:20:02 +0100 Subject: [Unison-hackers] future release roadmap In-Reply-To: References: Message-ID: On Sun, 13 Mar 2022 at 18:38, Greg Troxel wrote: > > 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.) This works now; really only testers are needed. https://urldefense.com/v3/__https://github.com/bcpierce00/unison/pull/566__;!!IBzWLUs!CcQG7V0gopr2CzS8ehNON4DcdxZlLrIkhCdpb82KAY6w8ewECIP71NSSEwfQMSZ3NCVODstsZaOQZg$ In addition to what you already mentioned, I also plan to open a PR which removes the Windows API stubs (added in 2009) because they are no longer needed since OCaml 4.06. This actually opens up for a great simplification of the System module and its usage but I hold that discussion for another time.