I'd try to do the same thing, just at the interface level, like the
kernel does. Eg, preadv2 as described at https://lwn.net/Articles/670231/
--dave
On 26/12/17 11:42 AM, Fabien wrote:
Thank you, lots of food for thought. For the go package-writer, now, I
guess the best practice so as not to be part of the problem is to
1- in minor revisions, of course, keep backward-compatibility.
2- in major revisions, either:
- make a new project, for instance, if my first project was
github.com/foo/bar, make a new one called github.com/foo/bar2 for
version 2,
- if applicable, keep the old directory structure as is for
backward compatibility, and make a new one for the new version, for
instance, if in github.com/foo/bar I used to define the packages
github.com/foo/bar/baz and github.com/foo/bar/foobar, keep them but
now recommend the use of packages github.com/foo/bar/version2/baz and
github.com/foo/bar/version2/foobar,
--
David Collier-Brown, | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
dav...@spamcop.net | -- Mark Twain
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
