To release version 8.3.0 or 9.0.0

[mcuee]

From here.

• Better documentation for compiling optiboot #355 (comment)

Someone authoritative should really make a decision here. Especially now that HEAD version of Optiboot has different compilation options to the 8.0 version that will definitely confuse many people / compilation systems once 9.0 or whatever is released.

@WestfW
It seems that the current git head is of version 8.3, just wondering if you want release it as Optiboot 8.3. That may help to reduce the confusions.

[WestfW]

/* 8.3 WestfW add section-start determination code to /
/ the C source. In theory, this causes no changes /
/ to the binary, but it's "risky", so ... bump. */

[mcuee]

@WestfW

Thanks for sharing the reason of version bump.

In any case, it has been 4 years plus since 8.0 release, so it is probably good to release 8.3 in the near future.

[hecko]

From my perspective it would be really great if Optiboot can move to semantic versioning and to release 9.0.0 instead of 8.3.0, since HEAD has breaking compilation flags/definitions against 8.0. Also it would then be possible to prepare a proper documentation for this release and have a more streamlined CI/CD environment.

My humble suggestions here:

• releases would be made more often reflecting 'Summary' section of https://semver.org/
• official documentation should be collected to only two places: source files (as of now) and GitHub pages (moving from GitHub wiki to more static official docs as part of the release package)
• add a reference build environment to the project using Microchips GNU toolchain as that is a supported toolchain by a company who actually makes the chips that Optiboot is used on.

The last point is sort of controversial, but the huge benefit is, that if an end user wants to do some optimization of the compilation process they have an official Optiboot project reference which WILL always work so end users can do their optimizations against a known reference.

I personally think, from my perspective as a user, that this would greatly improve the experience in interacting with the project.

[mcuee]

add a reference build environment to the project using Microchips GNU toolchain as that is a supported toolchain by a company who actually makes the chips that Optiboot is used on.

I think this is a good suggestion.

For one thing there is the AS7 but I am not so sure if it helps much.
https://github.com/Optiboot/optiboot/blob/master/optiboot/AS7/AS7-README.TXT

[mcuee]

releases would be made more often

That is the often the most difficult part for smaller open source project, unless more people come to help.

[WestfW]

In general, I prefer FEWER releases. Optiboot is supposed to be relatively DONE and stable. I feel like an important part of maintaining it is NOT accepting requests for changes. As it is, Arduino hasn't accepted an update since 4.3, MCUDude has switched to urboot, and DrAzzy has his own fork (and modifications for AVR-D*)

To bump the major version number, I feel like there need to have been significant changes in either the core functionality or the core targets (ATmega328p, etc) or major changes to the build environment (such as the makeopt stuff.) Adding new targets or rarely-used and only-maybe-working options (rs485. ugh) isn't enough.

I'm not clear on the relative advantages/disadvantages WRT the wiki vs a separate documentation directory, especially since I haven't allowed non-owner updates of the Wiki. The wiki allows for convenient online browsing - would that still happen if I move the .md files to the source repository?

When you ask for a reference build environment, are you talking about documentation-wise, or actually adding a copy of (eg) the microchip tools zip file to the Optiboot repository? I don't think I like the latter idea; all sorts of licensing issues, and it "freezes" at a point where toolchain updates that aren't a problem would be less likely to happen or be tested.