@pdeffebach & @mbauman Oh dear. I certainly didn’t mean to disparage DataFrames – and I’m thrilled to see 1.0. I enjoy using Tables very much, and look forward to using PrettyTables. We have a fantastic community with some amazing contributors.
@dilumaluthge Thank you for pointing to this other thread; I found tkf’s response informative, it references ticket #33047 and a Pkg3 thread discussion thread.
What I’m asking is… what makes those who have well-utilized packages so reluctant to tag 1.0 ? Is there another way?
I don’t think this is necessarily true. To many, there is a qualitative meaning of zero-point releases that indicates that the work simply isn’t ready to be maintained. While, once v1 is released, one expects a bit more stability. Once you tag v1.0 I think some may feel more constrained, introducing far less churn (and, also, less innovation). Perhaps this expectation and limitation may be what keeps many packages to zero-point releases, even well after they are broadly adopted?
Could we think of a different workflow?
Let me pick on myself. I’m reluctant to put HypertextLiteral at v1.0 – mostly, at this point, because I’ve not gotten enough community feedback. In particular, there are a few design choices I’m not so sure about… so, do I tag, or do I wait?
I think I should tag v1.0 soon. HypertextLiteral has reasonable documentation, test coverage; it is beyond minimum viable, and it has a growing user community. I think a v1.0 tag brings with it a commitment to only accept bug fixes or incremental improvements if they won’t break compatibility.
But then, what for the “next version”? What about the experimental features I’m musing about? With existing conventions, I’m put in a bit of a dead spot. How do you release new improvements, that might break stability? Is it v2.0 that you recommend people to -not- upgrade to?
So, taking inspiration from @quinnj 's JSON, JSON2, and JSON3 packages. Perhaps I should think of this as a fork instead? Just like JSON2, I might call it HypertextLiteral2.
- The
v1.0series remains quite stable in a branch, and users don’t need to suffer from the churn. - The experimental version can start at
v0.1which indicates that it is likely going to be unstable (or even abandoned!). - Those that want to provide feedback to the experimental version could install a different package. In fact, they could even install them side-by-side… if I don’t export too much.
- They could even exist in the same github repository, just in different branches.
- Once the experimental branch is stable enough, it could then be merged back into the main project, producing
v2.0.
Perhaps convention like this might help address a “reluctance gap” by providing a way forward that isn’t restrictive. More broadly, perhaps tagging Foo v1.0 is currently not an option if the author expects very significant changes in the coming year. However, perhaps by using a new package name, Foo2, they could starting from v0.1 again, and then, once it’s good enough for a general release, jump right to v2.0, and pull the entire updated version into the main repository.