changelog for 1.0

[minrk]

@GeorgianaElena I think we can make an 0.4.0b1 with this as it is and start asking folks to test it. WDYT?

[manics]

Now that this repo is back up to date is it worth going for a 1.0.0 prerelease instead?

[GeorgianaElena]

I'm +1 on making a release now.

Now that this repo is back up to date is it worth going for a 1.0.0 prerelease instead?

I also think that a 1.0.0 prerelease makes sense given the latest changes?

[minrk]

is it worth going for a 1.0.0 prerelease instead?

Maybe? I think we're still learning about traefik, so I'd feel slightly more comfortable with 0.4 for now. On the other hand, it's been used in TLJH for ages without apparent issue. WDYT @GeorgianaElena?

I think reasons to maybe consider it not quite ready for 1.0 are:

• this release needed a pretty substantial rewrite. it might be good to get some validation of that before calling it 1.0
• kv store support and clients #155 - it would be good to be in a healthier state re: kv store Python clients (e.g. add redis, drop consul)
• explore activity tracking via metrics #151 - activity tracking could be quite valuable, but there are challenges wrt

At the same time, I'm generally for the idea that the bar for 1.0 should be "people use this," which is clearly the case for us already.

[minrk]

Since you're both for 1.0, I updated it to 1.0. I think we're ready for a beta!

[minrk]

FWIW, should we put a deprecation on consul already, as discussed in #155 ?

[GeorgianaElena]

FWIW, should we put a deprecation on consul already, as discussed in #155 ?

I believe that deprecating it now that we're going for a 1.0 release makes sense.

[manics]

Do you envisage any breaking changes for #170 ? That would be a good reason not to go for 1.0.0.

[minrk]

Do you envisage any breaking changes for #170 ?

I don't think so - it should mainly be rewriting a private method or two that exist now into calling other slightly more generic methods.

I guess it would make the new generic methods reuqired for KV subclasses, but those don't exist outside this package, so I'm not worried about that.

[minrk]

Actually, looking at #170, I think it will probably be a pretty significant reorganization. It shouldn't be public-facing, though.

[minrk]

I went ahead with an implementation of #170 in #185 if folks want to have a look at that before making a release. It has no public-facing changes, purely internal implementation details other than #184 which rolls back an undocumented new feature in favor of simpler explicit config.

[minrk]

OK, updated with the latest PRs. Ready for 1.0b1!