Release version?

[petrkoutnycz]

Hey Andrew! Are you considering to to make a non-beta release of this nuget anytime soon? :-) Thanks!

[andrewlock]

As you may have surmised, not necessarily 🙈

[tomekjanicki]

Why not?

[andrewlock]

(This is a snippet from a post I'm working on, but it's a brain dump of my thoughts about trying to finally get a 1.0.0 out)

I've been very hesitant to put out a stable 1.0.0 release for the package, mostly because I don't really intend there to be a 2.0.0 unless there's a very good reason. The reason being is that I want consumers of the package to not have to worry about things breaking underneath them.

In terms of features, I'm pretty happy with where the generator is today compared to even a few months ago:

• Optional automatic support for System.Memory if it's available.
• Optional usage analyzers to encourage using the extension methods where possible.
• The extensible EnumParseOptions and SerializationOptions discussed in this post.
• Catering to "internal" usages of the generator (where you don't want downstream consumers to be aware you're using it).
• Support for enums defined in other libraries (including BCL enums)

Nevertheless, there are a few things I'm not entirely happy with. For example:

• The usage analyzers are IMO pretty cool, should they just be enabled as warnings by default?
  • Presumably, if you're adding this package, you want to preferentially use them, which would suggest yes, enable them.
  • But on the other hand, that would potentially be a big breaking change and annoy a bunch of people that just have a targeted usage
  • However they could just disable them in that case.
  • Unfortunately, you need to "preserve attribute usages" if you want the analyzers to work in "downstream" projects and ensure you don't exclude runtime assets, but that's maybe just a limitation we'll have to live with 🤷‍♂️
• The nested runtime dependency types are pretty ugly
  • Should they just be omitted/made private implementation details entirely?
  • My concern is that while they're a neat solution to a problem, maybe they should just be omitted (or made private, depending on complexity) to reduce confusion. The onboarding story becomes easier in this scenario: "add the NetEscapades.EnumGenerators.RuntimeDependencies package and get these extra features".
• You can't use "target-typed" new on the EnumParseOptions and SerializationOptions overloads due to ambiguity with existing methods (shown below)
  • This is really annoying, but I think the only way to "solve" it is to remove the overloads that contain the same number of parameters, which is again, pretty disruptive, and those methods are there for a reason (convenience)!
  • But maybe it's worth seriously entertaining making that break sooner rather than later.