kMutagene
commented
1 year ago In general I handle everything that has a 0 as major version as 'dangerous', so i don't think we need additional specifiers. We can also break as many API endpoints as we like as long as we do no not increase the major version beyond that.
See semver:
Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.
Regarding automating nuget releases (e.g. on a commit basis) I am kind of torn - it adds significant overhead to CI and is really spammy on the nuget feed. The nuget feed also takes some minutes to actually publish the package to clients, so its not instantaneous either way. I would still add a manual trigger for a nuget release, e.g. someone running the publishNuget target in their terminal.
Everything else is basically automated already:
- the
packtarget creates nuget packages - and the aforementioned
publishNugettarget can even used to programmatically push the package to nuget (given aNUGET_KEY_CSBenv variable containing a nuget API key)
So in short:
- I'll release a nuget package with the current contents as v0.0.1
- add everyones nuget accounts to the package, i'll need you account names for that
- I think we'll need a
fslabnuget organization eventually, but we'll need an organization email for that.
HarryMcCarney
We need to process for automating the publishing of nuget packages from sprint releases.
This will make Michele's testing feedback easier (he can reference the current version in fsx rather than having to build locally) and I think rapid iterative publication will improve quality faster.
I think we could publish v0.1 to the public nuget feed. Clearly we will need to caveat it with "alpha version - unfit for consumption" etc. Alternatively we could use a private package manager.
Happy to discuss.