Skip to content

Start planning for 1.0 #726

Open
Open
@Susurrus

Description

@Susurrus

I've been thinking about this recently as the discussion of breaking changes comes up regularly in PR reviews. I wanted to start bringing things to the table to make sure we were headed in the right direction for a 1.0 release. I think things will need to be resolved a little better with libc before we get there, but I'm expecting this to be about a year away unless things speed up in the refactoring department.

I think we should aim towards a minimal 1.0 release, so we wouldn't have any sort of goal in terms of features, but really a goal in terms of API quality & stability. At the bare minimum this is:

  • Upstream all constants & ffi declarations
  • Provide extensive documentation for all APIs.
  • Decide on common interface types (TimeValLike vs Duration, CString versus String, etc.).
  • Finalize how we want to expose constants (do we make people use libc:: types or re-export them from nix?, Do we rename things nicely or use the original names?).
  • Do we really want to have an RFC process or are just issues here good enough?

I think once that's all done we could do a 1.0 release.

There's also the option of trying to focus all efforts towards this and refusing PRs that don't move towards these goals (as in add features). I think we're a ways out from this, but it might be a good idea as we get closer for a final push.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions