I would like to release flashrom-1.0 before the weekend.
There was a bit of discussion on IRC tonight and I found there are others who are also looking forward to a release.
Not so much because we think flashrom is currently in a particularly awesome state, but rather because we would like to get it packaged, distributed, used and marketed more - and that is really all version numbers are good for anyway.
There are many pending patches in people's working copies that are on their way into the repo, and that is great. I would like nothing more than to make a 1.1 release shortly after 1.0, and I hope noone feels that flashrom should freeze somehow just because it now has a version number.
I think flashrom will always be work in progress to a high degree, especially since the probing can never be fool proof because of our dearest PC architecture, but I still would like to make releases.
While some parts of trunk flashrom may not be production quality, there are some parts that are indeed production quality and that have been heavily used. I think 1.0 is a nice round number and a great starting point for future improvements. It also communicates the fact that at least parts of flashrom are very good and quite usable, as has been the case for several years already. :)
I've made a preliminary roadmap or action plan for 1.0:
1 handle the possibility of NULL flash chip function pointer derefs 2 add a tested flag to the flash chip table, most will be untested now 3 Carl-Daniel has a patch with fake flash chips of different sizes that is good to let people at least read the flash chip even if there is no support. Either this goes in as is and we add a -C --force-chip option (or similar) or we could make a special --force-read command to avoid cluttering the flash chip list with dirty fake chips. 4 go over text output to find and do possible UI improvements 5 change -s and -e into -S and -E, and change -E into -e with the rationale that erase is much more common than "exclude end position" 6 make probes advisory rather than controlling? always have the user confirm the probed chipset before continuing?
I can do 1, 2 and 4. If there is agreement I'd love to do 5 too.
In 4 I include adding a message for the user about the mainboards that need to be specified manually when board probing fails.
Please share your thoughts - and in particular anything on 3 or 6.
The plan is to create a repos/tags/flashrom-1.0 tag of the rev that goes into release, and publish the release with a tarball on the Flashrom wiki page.
For a bit of fun (gotta have some fun! :) we can have codenames for releases when we feel like it, the 1.0 favorite is "apt apology."
Objections? More must-have stuff before 1.0?
I don't want to add too much stuff, just trim away the worst rough edges and make a release very soon.
//Peter