> To sum up: only the latest version of a dependency will be listed in > the version notes
Great. > but in this case (if the vulnerability can have large impact) we are > preparing a fast track release (e.g. 2.5.10.1) - in this case the list > of changes is none or very minimal True, those changes were minimal. * in this case if S2-047 or S2-049 apply to you you still need to upgrade * when there's no large impact vulnerability, companies are not always willing to allow the upgrade (mine doesn't due to budget + capacity), meaning you have to upgrade a couple of versions at that time. > I do not really grasp what you mean by that All i meant was that when you need to do a quick upgrade for security reasons, you want it done and running in production as quickly as possible. This was already countered with * your previous answer concerning 2.5.10.1 * Usually the quick workarounds without upgrading, if they exist, also get mentioned in the vulnerabilities > Yes and this additional issue type should allow easily identify such > duplications when assembling a version notes - all the changes in > dependencies will be listed in a one place :) Great. In short: Seems good to me. Thx for considering this :-) Regards, Stefaan Dutry (sdutry) 2017-07-14 9:14 GMT+02:00 Lukasz Lenart <lukaszlen...@apache.org>: > 2017-07-14 9:04 GMT+02:00 Stefaan Dutry <sdu...@apache.org>: >> What happens when a dependency gets updated multiple times in a >> release? Will it be listed multiple times (since it shows all issues >> with that type)? > > It will allow me (or anybody other) quickly figure out the duplication > and I can just leave info about the latest version of the dependency; > and remove the others as I did in announcement > http://struts.apache.org/announce.html#a20170717 > > To sum up: only the latest version of a dependency will be listed in > the version notes > >> My reasoning was: >> * When you need to do a quick upgrade due to a fixed vulnerability you >> just want a quick checklist of the things that need to be >> changed/checked > > but in this case (if the vulnerability can have large impact) we are > preparing a fast track release (e.g. 2.5.10.1) - in this case the list > of changes is none or very minimal > >> * At that time the developer doesn't realy care for the other >> improvements/upgrades (which are already listed now, and can be >> checked by anyone interested) > > I do not really grasp what you mean by that > >> * When a dependency gets updated multiple times, the only version of >> interest is the one used in the release. > > Yes and this additional issue type should allow easily identify such > duplications when assembling a version notes - all the changes in > dependencies will be listed in a one place :) > > > Regards > -- > Ćukasz > + 48 606 323 122 http://www.lenart.org.pl/ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org