binary incompatible updates for curl and neon
Hey, I plan to update curl to 7.16, and neon to 0.26.x (as subversion finally supports it) soonish. Just as a little reminder for those of you maintaining ports depending on those. Also, I was wondering whether we should have a "[binincompat]" flag similar to the "[security]" one, to automatically trigger informations for other maintainers; this message could contain information (or a link to it) how to deal with that; typically that would be simply test and update the release to enforce a rebuild. Comments? Best wishes, Johannes -- Johannes Winkelmann mailto:jw@smts.ch Zurich, Switzerland http://jw.smts.ch
Johannes Winkelmann wrote: Hi,
Also, I was wondering whether we should have a "[binincompat]" flag similar to the "[security]" one, to automatically trigger informations for other maintainers; this message could contain information (or a link to it) how to deal with that; typically that would be simply test and update the release to enforce a rebuild.
Good idea. I think we could even expand it to something like a generic [notify] or [important] flag so we have a way to inform people of relevant updates (ie the j2re > jre rename), and put directions in the commit message. On a related note, the notify script needs some rewriting since it actually does not understand pushes with more commits. Will look into it this week. Regards, Simone
Simone Rota wrote:
Johannes Winkelmann wrote:
Hi,
Also, I was wondering whether we should have a "[binincompat]" flag similar to the "[security]" one, to automatically trigger informations for other maintainers; this message could contain information (or a link to it) how to deal with that; typically that would be simply test and update the release to enforce a rebuild.
Good idea. I think we could even expand it to something like a generic [notify] or [important] flag so we have a way to inform people of relevant updates (ie the j2re > jre rename), and put directions in the commit message.
On a related note, the notify script needs some rewriting since it actually does not understand pushes with more commits. Will look into it this week.
Good idea, Johannes. I also agree with Simone that a generic flag could be used to encompass incompatibilities, renames, structural changes (/home/www -> /var/www), etc. I anticipate these occurances would be relatively sparse, so users would not mind subscribing to one list to see all of them. +1 -- Jay Dolan jdolan.dyndns.org A: Because it's annoying to read. Q: Why is top-posting bad? A: Top posting. Q: What's the most annoying thing about usenet?
Jay Dolan wrote: Hi,
Good idea, Johannes. I also agree with Simone that a generic flag could be used to encompass incompatibilities, renames, structural changes (/home/www -> /var/www), etc. I anticipate these occurances would be relatively sparse, so users would not mind subscribing to one list to see all of them.
I've written a new script which properly splits up the commits in a git push. I added a single [notify] flag that will be used for important notifications, being them security related or not. I don't think it's worth having different flags right now, because we don't distinguish recipients, additionally a single tag is easier to remember ;-) Regards, Simone
Hello, On 2006-11-08 at 11:42, Simone Rota wrote:
Johannes Winkelmann wrote:
Also, I was wondering whether we should have a "[binincompat]" flag similar to the "[security]" one, to automatically trigger informations for other maintainers; this message could contain information (or a link to it) how to deal with that; typically that would be simply test and update the release to enforce a rebuild.
Good idea. I think we could even expand it to something like a generic [notify] or [important] flag so we have a way to inform people of relevant updates (ie the j2re > jre rename), and put directions in the commit message.
+1 -- Antti Nykänen | aon@iki.fi | http://aon.iki.fi/
participants (4)
-
Antti Nykänen -
Jay Dolan -
Johannes Winkelmann -
Simone Rota