Hello! > Proposed release date: 2027-01-29 (a Friday), exactly 25 years since Ron > Minnich’s 'Dammit' commit, which is essentially where the project began. A > project only gets one 25th anniversary.
Oh, 25 years! <3 Thanks so much for noticing and bringing this up - I totally missed it! I remember I was looking at the beginnings of git history last year, when we were creating the Hall of Fame, and somehow did not realise that Jan 2002 has 25 years coming soon! I don't want to miss the date, yes it only happens once :) I checked the git history right now, and after some thinking: the very very first commit actually says "Trying to make this general purpose user-land flash burner". This is perfect, and let's take this one as a starting point. Date: Tue Jan 29 18:21:41 2002 +0000. (Dammit was later, and also there was more than one... So user-land flash burner it is ;) ). Greg, I understand you have concerns about rushing (i.e. the quality). I don't like rushing myself and we won't be, and we will be doing two things at the same time: being excited about the 25th anniversary and taking care of the release quality. More specifically, > 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*. We have a release process documented ;) and it has been followed since the time it was published: https://flashrom.org/dev_guide/release_process.html This process we used starting from v1.4, which means 4 times already. It worked so far, so we will continue using it. The release date is always planned, and the dates of feature freeze are planned as well. All of this is announced on the mailing list, so no surprises, anyone who is interested can get official information. You can check, I was posting updates on the list about how the process is going, each time. With dates, and details which bugs have been fixed in each RC. The bug fixing window, so far we were doing either 3 or 4 weeks. Maybe for the "end of year holidays" time the window can be longer because lots of people are away. > and then *actually follow the rule* Of course, as always! About versioning. I would follow the usual process and not skip a version. Realistically, for us it means we can have 1.8.0 and then 2.0.0, so we go from 1.x to 2.0. I believe this does not count as "skipping version". Just instead of incrementing x we go level up. For dropping things (programmers this time), we can do the same way we did when dropping makefile. Announcing (in advance) that release 1.8.0 is the last to include <list of programmers>. After 1.8.0 is done, all of them can be dropped. 2.0.0 will be the first one without them. This means rayer_spi will stay for a bit longer... but I think it's fine. 2.0.0 can be settled at 2027-01-29, this is special date, bug fixing window opened in december 1.8.0 to be decided > I have used this approach successfully in projects I maintain. An unusual > version number draw attention, which is exactly what I want before removing > long-standing functionality. While I think this is indeed an unusual approach to "draw attention", I won't be questioning that it can work for other projects. I am sure you do the best for the projects you maintain! But I think it's too unusual for flashrom, so I wouldn't use it (I wrote above about versions). We draw attention by posting on the mailing list. People can also check release notes on official website, also a "Recent development" page with everything that is planned for the next release. That's basically the approach: two official sources of information, mailing list and website. Everyone who is interested can follow, it's all public. > A few months ago I ordered thousands of SKUs from China. <...> Once the > packages finish arriving, I'll spend a few weekends testing every > currently-unverified chip. I just want to stop and say: this is incredible! Thank you for your work! > I would like libflashrom to become the de-facto low-level library that other > projects build on That would be great indeed. Do you use libflashrom in your project(s) already, or planning for future? Have you seen libflashrom bugs? I am asking because at the moment most of the user reports/questions are coming from command line usage, and not much from actual libflashrom users. Yes, our own cli is using our own libflashrom, but "pure" libflashrom use case is a different thing. > this is an RFC, not an announcement Yes! this is a discussion, let's gather thoughts and ideas. For anything that's decided, there will be an announcement later. On Sat, Jul 4, 2026 at 2:22 AM Greg Troxel <[email protected]> wrote: > > "Abdelkader Boudih" <[email protected]> writes: > > >> If it's a normal stable release there is no reason to use an unusual > >> version number. Irregular versioning raises the "what are you thinking, > >> and why?" question. > > > > The version bump is intentional. > > > > My thinking is that many flashrom users dont follow the mailing list or > > GitHub (they also got used to append only release). > > They will simply see their package manager offering an upgrade from 1.7.0 > > to 1.9.0 and wonder, "Why was 1.8.0 skipped ?" That curiosity increases the > > chances they will read the release notes and speak up before the 2.0.0 > > removals. > > > > I have used this approach successfully in projects I maintain. An unusual > > version number draw attention, which is exactly what I want before removing > > long-standing functionality. > > > > I prefer to have people wonder than later say, "I only discovered the > > change after my automation started failing because the programmer list had > > changed and assertion failed" > > I don't think this is an ok practice. > > Plus, you said the withdrawals will happen in 2.0.0, and that the next > release will not have breaking changes. > _______________________________________________ > flashrom mailing list -- [email protected] > To unsubscribe send an email to [email protected] -- Anastasia. _______________________________________________ flashrom mailing list -- [email protected] To unsubscribe send an email to [email protected]
