Why not consider the new feature an extension to the extension… and hence something which doesn’t require a bump of the extension being extended?
— Kurt > On May 30, 2015, at 1:54 AM, Dave Cridland <[email protected]> wrote: > > > > On 30 May 2015 at 08:33, Georg Lukas <[email protected] <mailto:[email protected]>> > wrote: > * Steffen Larsen <[email protected] <mailto:[email protected]>> [2015-05-30 > 08:37]: > > No, I would go for a version bump, because it could break some clients. > > A version bump, on the other hand, would break all clients. Some clients > haven't yet implemented the sm:2 to sm:3 bump, and implementing > different versions of the protocol in parallel is not always trivial. > > > In fairness, a version bump is only problematic because of inertia and > lethargy, not because of any real difficulty, especially where the two > versions are identical in practice (as with sm:2 and sm:3). It does introduce > a delay in implementation, but then, clients supporting sm:3 wouldn't be > supporting sm:3+h anyway. The question is really whether we want servers to > have to support sm:2, sm:3, and a new sm:4 all of which are virtually > identical. > > +1 for the new feature. > -1 for the version bump. > > > FTR, I would be +1 on the feature obviously, but I'm ambivalent to the > version bump. I'd simply like to have the discussion so that Council can > advise the Registrar properly. > > Georg > -- > || http://op-co.de <http://op-co.de/> ++ GCS d--(++) s: a C+++ UL+++ !P L+++ > !E W+++ N ++ > || gpg: 0x962FD2DE || o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+ || > || Ge0rG: euIRCnet || X(+++) tv+ b+(++) DI+++ D- G e++++ h- r++ y? || > ++ IRCnet OFTC OPN ||_________________________________________________|| >
