On Sat, Sep 02, 2017 at 09:19:50PM +0000, Guenter Milde wrote: > Dear Scott, dear Enrico, dear lyx developers, > > On 2017-09-02, Scott Kostyshak wrote: > > On Sat, Sep 02, 2017 at 12:34:05AM +0200, Enrico Forestieri wrote: > >> On Thu, Aug 31, 2017 at 08:53:41PM +0000, Guenter Milde wrote: > > >> See above. Release notes should be used to illustrate current changes, not > >> changes occurred in past releases. > > > From what I understand, if we could go back in time (but could not fix > > anything in the code), we would add notes to release notes for the LyX > > 2.2.0 release. That is not possible. So the question is do we put them > > in the release notes for 2.3.0 or leave them absent from any release > > notes? > > We cannot go back in time, but git branches allow at least a fix: we > can amend the RELEASE NOTES in the 2.2.x branch.
I'm not sure about this. I do not think users expect the release notes to change. > The question is, who is > going to read it? > > > I wonder if a similar situation has come up before and what we did. > > > It is true that we have a subsection "Caveats when upgrading from > > earlier versions to 2.3.x", and indeed 2.1.x is an "earlier version". > > However, the title of the file is "Important Changes in LyX 2.3.0", > > which in my opinion dominates any implication of a subtitle. > > Some consequences of the changes in 2.2.0 came only to our attention during > the 2.3 development cycle. IMO, it is a pragmatic solution to add this > insight in the 2.3 RELEASE NOTES. I see your point and agree that the information needs to go somewhere that could be accessed by users. > > One line of logic is: suppose the release notes for 2.2.0 were accurate. > > Do we really think that 2.1.x users would read both the release notes of > > 2.2.0 and of 2.3.0 before upgrading? Probably not. So the fact that the > > release notes for 2.2.0 are inaccurate might not be so relevant. This is > > all just guessing about user-behavior on my part though. And I must > > admit that when I personally upgrade software that's important to me, I > > would read all of the release notes in-between. > > > I think the best solution might be the following: > > > In the RELEASE-NOTES file, we could reference > > https://wiki.lyx.org/LyX/ReleaseNotes for release notes relating to > > previous versions of LyX. Actually, I need to update that Wiki page. > > e.g. we could put "If upgrading from a pre-2.2 LyX version, please see > > https://wiki.lyx.org/LyX/ReleaseNotes";, and on that Wiki page we can > > list both the original release notes as well as any "post 2.2-release > > addendums", where issues such as what Günter details could be listed. > > If it is decided that this proposal is too complicated, we could > > perhaps include a very concise note in the 2.3 release notes along the > > lines of "if upgrading from pre-2.2, please read <referencec> for > > considerations related to dashes". > > The problem is, however, that users upgrading from 2.2 have read the > 2.2.0 RELEASE NOTES already and won't see the need to re-read them, Agreed. > thus > missing the information. Nevertheless, they are still affected by the > changes when opening pre-2.2 documents (and will forever, as we voted not > to revert the decision to merge literal and ligature dashes in the LyX > source). You are thinking maybe of a user who created their document with 2.1.x, edited it briefly in 2.2.x but not enough to realize a change/problem, and now are upgrading to 2.3.0 and will be reading the release notes? I think we can address it with e.g. a concise "if you created the first version of your document in LyX pre-2.2, your dashes may have been changed. For more information, please see..." I think that makes more sense that putting a lot of details about this issue in the 2.3.0 release notes. I think that the important thing is to let the user know the conditions under which they might experience a caveat. I don't really have a strong opinion on this, but I think a concise description of the conditions for a caveat, combined with a reference for further information, could be a reasonable compromise. Scott > A link to the ReleaseNotes wiki page is still a good idea, as we do not > ship a "Changelog" file. > > Günter > >
signature.asc
Description: PGP signature
