Hi Michael, > > We would prefer to refer to the release to 8.2508.0, as there are no > > changes at all in rsyslog itself. Also not in the doc, but of course > > there was a cleanup to the tarball. Most importantly, I do not want to > > continue the non-cleaned-up tarball. I know that using the same > > tarball name may interfer w/ caching. So I know this would not be a > > perfect solution. Forcing an update without any real changes on the > > user base IMHO is also not an optimal solution. So I am a bit > > undecided. > > > > I usually do prefer if in such a case a new tarball with a changed > version is released as this is a clear signal to users / distro > packagers that something has changed in the tarball (which strictly > speaking is the case here). > It's a bit odd if a release tarball ends up in a distro that differs > from the upstream release tarball (some people do actually compare the > checksum to see if a tarball has been tampered with). > I dunno if other distros have already updated their rsyslog packages > to 8.2508.0 (and if they care about such issues). > At least for Debian I had put the upload on hold. So from my side / > Debian I wouldn't complain too loudly if you reused the same version > number.
I asked a bit more around, and it seems to be acceptable in this specific case to just update the tarball. As such, I will now do so. If further need arises, I will craft a new release, which overrules the .0 in any case. I will not prepare the final post release merge and tagging. Once again thx for your input. Rainer _______________________________________________ rsyslog mailing list https://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
