Tom Gillespie <tgb...@gmail.com> writes:
> Semver is unlikely to help because the question is what is "broken" by > a change in version. Semver would likely be about breaking changes to > internal org apis, not changes to default behavior that affect users, > so you have two different "semantics" which put us right back where we > are now -- to know what really changed you have to read the NEWS. > Bastien has also talked about hear-ye versioning, which says when a > version changes users need to read the news. Best, > Tom > The 'hard' part of me says that if you upgrade org to a new major version, don't read the NEWS file and are then surprised by changes, you get what you deserve. Perhaps a tad too hard, but I do think users need to take more responsibility here. At the same time, I do think there are some things we could do to help them. I've mentioned in another message that the way MELPA and other repositories report versions is not helpful. All I get from the package names now is that a new version has arrived and the date it was released. There is no indication whether the new version is just bug fixes, new functionality or a major new version. I only know this by following this list. What can we do to encourage users to read the NEWS file? Would it be feasible to add code so that the first time someone opens an org file after a major version upgrade the NEWS file is displayed? Would it be useful to document ways of pinning package versions or implementing package rollback functionality? -- Tim Cross