Thanks for the feedback Greg. Just to clarify, this is an RFC, not an announcement. The roadmap is intentionally open for discussion and will evolve as people provide feedback and as circumstances change. I'm proposing a direction only.
Regarding the release date, it is still about seven months away, so I dont see it as encouraging anyone to rush. Rushed releases usually happen because there is pressure from shareholders, customers, conferences, or promised features. None of those apply here. The only thing I call 'urgent' here is that Flashrom only gets one 1/4 century anniversary. That is a milestone we cant recreate a month later, so we rather fit the release to the anniversary than fit the anniversary to the release. Regarding the versioning: 1.9.0 is intended to be a normal stable release, not an alpha or preview of 2.0. The idea is to collect the pending fixes, refactoring and documentation improvements into one last 1.x release, giving users a stable upgrade path before any removals happen. That is why Iim proposing 1.9.0 instead of 1.8.0. If majority prefer to just skip 1.9.0, that also fine. 2.0.0 is where I will make the breaking changes by removing legacy programmers that are effectively unmaintainable and no longer testable on existing hardware. The fact that this naturally aligns with the project’s 25th anniversary makes it an ideal milestone for a major version bump. As for what makes 2.0 different, it is not just the programmer removals. I would like to like it to represent a shift in focus: from carrying decades of historical baggage to maintaining a smaller, actively testable programmer set, while substantially expanding the catalog of verified flash chips. To me, that’s a meaningful project milestone worthy of a major version. If the that sound good, we freeze the submission of CB:93706, until after 1.8/9 is released. I did remove all the legacy programmers locally, so once are ready, i will open all the diffs. Thanks, Abdelkader On Fri, 3 Jul 2026, at 14:20, Greg Troxel wrote: > My quick thoughts from a lurker/packager who hasn't been paying > attention much. > > Planning a release date seems unwise. Structurally, that leads to > rushing. If you really mean January 29, I think you should put the > release branch in feature freeze (bug fixes, doc fixes) on November 29 > and cut a beta, and then on December 29th cut an rc, with the rule > being changes only for regressions from the last stable release, and > then *actually follow the rule*. I have seen many projects not really > take pre-release freezes seriously enough. If you violate the freeze, > then I think you need to push the release date out to T+30days. > > I see talk of 2.0, but I don't see planned breaking changes. So I am > befuddled by the grand plan. Perhaps it is to denote "all available > chips tested", in which case the NEWS should be very clear about that > vs breaking changes. > > As for 1.9.0, it's unclear if that is meant to be a departure from the > stability of the previous 1.N releases. If it is, it should be > 1.99.0, which is code for alpha towards 2, whereas 1.9.0 is a normal > release number. > >
_______________________________________________ flashrom mailing list -- [email protected] To unsubscribe send an email to [email protected]
