On Fri, Jan 13, 2017 at 4:54 PM, Dima Pasechnik <dimp...@gmail.com> wrote: > > > On Friday, January 13, 2017 at 3:41:23 PM UTC, Erik Bray wrote: >> >> On Fri, Jan 13, 2017 at 4:32 PM, Dima Pasechnik <dim...@gmail.com> wrote: >> > >> > >> > On Friday, January 13, 2017 at 11:15:49 AM UTC, Erik Bray wrote: >> >> >> >> On Thu, Jan 12, 2017 at 9:48 PM, Kwankyu Lee <ekwa...@gmail.com> wrote: >> >> > >> >> > >> >> > On Thursday, January 12, 2017 at 8:10:54 PM UTC+1, Dima Pasechnik >> >> > wrote: >> >> >> >> >> >> >> >> >> >> >> >> On Thursday, January 12, 2017 at 6:01:55 PM UTC, Volker Braun wrote: >> >> >>> >> >> >>> The whole point of NEWS would be to have coarser granularity than >> >> >>> individual tickets. E.g. 7.4 -> 7.5 is over 300 tickets, and a >> >> >>> 300-item list >> >> >>> is never a good answer to the question "whats new in this release". >> >> >>> I >> >> >>> would >> >> >>> envision a list of, say, 10-20 highlights to have associated news >> >> >>> fragments. >> >> >> >> >> >> >> >> >> yes, right, so you'd tag these "interesting for NEWS" tickets on >> >> >> trac, >> >> >> using some kind of trac plugin. >> >> > >> >> > >> >> > I guess Volker's idea is that the author of the ticket decides if >> >> > his/her >> >> > ticket is worth to be highlighted and provide a well-phrased blurb >> >> > for >> >> > general users. >> >> >> >> Yes, I support this. The idea is to have a high-level view that end >> >> users can digest as to what changed as it impacts them. This >> >> certainly *should* include bug fixes, but we're talking especially >> >> runtime bugs that are fixed from one release to another (as opposed to >> >> bugs that only occur during development and which appear and are >> >> subsequently fixed only during development). Sometimes also build >> >> bugs are worth reporting if, for example, building on a particular >> >> platform is fixed between two releases. And of course new features, >> >> etc. >> >> >> >> If you autogenerate such a list just from ticket summaries or worse, >> >> from the git changelog, it's not very digestible in that way. I'm >> >> glad adding such a changelog is on the agenda. >> > >> > >> > at least you're autogenerating from something that is visible and >> > reviewed. >> > Reviewed these extra pieces, as Volker proposes, to be written is an >> > extra >> > burden. >> >> You're basically saying that writing good documentation is an extra >> burden. And of course that's true. But that's not an argument >> against it. > > > it's not really documentation, it is more of advertising! > > some kind of write-once read-never thing, many people won't be bothered.
Except when they have a problem (and often even when they don't, such as to check whether they can expect any problems with their code when upgrading to a newer version--for example this is a place to announce deprecations and API changes). I find it infuriating when projects don't supply such a change log (especially if I do have a problem). It's almost as infuriating when they don't timestamps in their changelogs and there's no way to know when a version was released, which is sometimes useful information. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
