If you use protobufs and the current guidelines you can always add new fields.
> On Mar 11, 2021, at 12:43 PM, 'Axel Wagner' via golang-nuts > <golang-nuts@googlegroups.com> wrote: > > > Hi, > > in some sense, every change to an exported symbol is a breaking change. So a > straight-forward "does this change have the potential to break a reverse > dependency" is simply not the best way to look at compatibility. We need more > nuance. > > In general, I believe it would be fair to tell the consumer of a struct that > if they want to be guarded against this kind of breakage, they can't use the > conversion-ignoring-struct-tags utility, but have to copy the fields one by > one. That is similar to how we already tell the consumers of a struct that > they need to use struct-literals with field-names. > > To the producer I would say that they should consider how a struct is used, > to decide if something is a breaking change or not. For example, I believe it > would be fair to assume that an http.Server is not something that would be > serialized so there would likely be little need to consider adding a struct > field a breaking change. But something like a jwt token, or other > plain-old-data struct types should probably be aware of this and might have > to consider adding a field a breaking change. > > In either case, I think you bring up an interesting case that I haven't > thought about, before. Personally, I feel that at its core, the approach of > controlling encoding behavior via struct tags just isn't friendly towards > other packages re-using the same type, but changing encoding aspects. > Allowing conversions to ignore struct tags was a way to remedy that, but as > you demonstrate, that's still far from ideal. > > So perhaps what we should do is discourage new encoding packages from > coupling options to the type itself and instead encourage pass them to the > encoder directly - or at least providing the option to do so. At the end of > the day, Go gives authority over a type to the package defining it, both in > terms of what the language allows and in terms of domains of breaking > changes. So if we want to enable people to re-use a type with different > encodings, we should have a way to customize the encoding behavior of types > without having to touch them directly. > >> On Thu, Mar 11, 2021 at 6:15 PM 'Colin Arnott' via golang-nuts >> <golang-nuts@googlegroups.com> wrote: >> When working with wire formats, serialisation, and external types, it is >> useful to change the struct tags: https://play.golang.org/p/h6b6FmeDuaR. But >> when the original struct has a field added, this breaks: >> https://play.golang.org/p/VHmV9r2MxNt. It seems like a foregone conclusion >> that we suggest against adding a struct field because it is a breaking >> change. That said, we probably do not want to restrict the ability to >> convert structs as it is really helpful. Is this a known issue or previously >> discussed topic? If not what if anything should be done to clarify best >> practices? >> >> -- >> 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. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/golang-nuts/dcdcbd6a-838e-47c1-8b3d-935d485d96b5n%40googlegroups.com. > > -- > 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. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/CAEkBMfGp%2B%2B90tK1A-Sti1wjap%3DXxBU-QfrE1ReUSCYDt75tmHQ%40mail.gmail.com. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/8B757F98-CF4F-43D5-A8EB-0621BDFE2DD0%40ix.netcom.com.
