search

CuriousScientist0 / ADS1256

An Arduino-compatible library for the ADS1256 24-bit analog-to-digital converter.
MIT License
31 stars 11 forks source link

Example broken in 1.2.0 #17

Closed BenjaminPelletier closed 1 month ago

BenjaminPelletier commented 1 month ago

The example sketch at the v1.2.0 tag does not compile because of an extra closing parenthesis on line 178.

CuriousScientist0 commented 1 month ago

I know, but I don't have the time to fix it and release a new fix for it at the moment. Those who want to use the library should know how to delete a parenthesis anyway. :)

BenjaminPelletier commented 1 month ago

It is...bold...to close an issue that prevents users from using a product without fixing the author's mistakes. At a minimum, I would expect this issue to remain open until you do have time to actually fix it and release the fix.

CuriousScientist0 commented 1 month ago

Umm, the .ino file is fixed. I just did not have the willpower to go through all the mess to refresh everything to make the fix sync with the Arduino Library manager. Sorry for closing the issue 5 minutes earlier than committing the fix...

BenjaminPelletier commented 1 month ago

The usual sequence of events would be:

  1. Commit fix to main branch ("commit" here includes pushing to the GitHub repo since the subject of the GitHub repo, including Issues, is the GitHub repo itself, not a developer's local clone of the GitHub repo)
  2. Create release including fix
  3. (optional) Verify fix addresses users' problems
  4. Close issue

The reason for this order is that an issue is still a problem for users until released software resolves it, and "closing" an issue generally indicates resolution for users. Executing step 4 five minutes before step 1 would be a surprising approach in standard software development. The more common alternative would be commenting on an issue that it is resolved locally prior to step 1 and/or commenting that it is resolved on the main branch between steps 1 and 2 (though these tracking comments are not required by standard practice). For instance, note that FastLED#1656 is currently still an open issue even though it is resolved on the main branch.

As a second note, standard semantic versioning increments the middle number when something backwards-compatible has been added (new feature, old user code should still work). The last number is incremented when something is fixed or updated, but no features were added and old user code should still work. So, I would have released the parenthesis fix as 1.2.1 rather than 1.3.0. I would not, however, try to go back and change 1.3.0 to 1.2.1 -- this is just a note for the future :)