search

otakup0pe / avakas

Tooling to assist with Semantic Version Manipulation and Representation
http://ohno.computer/post/144362045508/a-codified-opinion-on-semantic-versioning
MIT License
2 stars 5 forks source link

How is avakas published? #78

Closed tyler-jachetta closed 3 years ago

tyler-jachetta commented 3 years ago

if I want to start using the new (1.0.13) patch of avakas, is there a pipeline somewhere setup to deliver that to pypi, or is that handled manually at this time?

otakup0pe commented 3 years ago

Hmm it should handle the pypi upload on tagged commits to mainline branch.

tyler-jachetta commented 3 years ago

hrm, pypi still thinks it's on 1.0.11, I don't see anything in the github actions for pypi, but there is a docker container that is pushed

tyler-jachetta commented 3 years ago

https://pypi.org/project/avakas/#history

otakup0pe commented 3 years ago

I know @mjuarez did some work on the release recently but I'm not sure if the docker container is actually consumable (it wasn't when I wrote #31 )

There is pypi stuff in the release workflow.

mjuarez commented 3 years ago

You create a release from the github tag. that should trigger the action to upload. Covered in: https://github.com/otakup0pe/avakas/pull/51

Maybe the process should be captured as a Wiki note for project maintainers rather than a README unrelated to the software package itself?

tyler-jachetta commented 3 years ago

1) should I be creating releases when I merge something in then (or is that administratively above my pay grade? 2) Is there a reason we don't want a release created on every mainline non-prerelease tag? see the comments in about too many uploads in #51 but not sure if that's still relevant with good prerelease hygene (and not automagically uploading prereleases)

otakup0pe commented 3 years ago

I'd rather not see pypi pushes for every single prerelease. We could keep them as github releases/artifacts though?

tyler-jachetta commented 3 years ago

oh definitely not suggesting any automatic pushes for any prereleases, only full releases in mainline

mjuarez commented 3 years ago

The reason I had made release process manual was a comfortable middle-ground from previous behavior. Originally, we would only increment a version based on a commit message hint. This was the mechanism to gate releases to pypi. However, a problem existed where the developer had to remember to add the hint to the commit message if they made a change. If they forgot, no version would be made and no deploy to pypi would be made. The workaround would have been to amend your commit and force push, or do an empty commit.

Instead, I proposed moving to versioning on every push to this repo and only relying on hints as modifiers from a default bump level (patch). Instead of pushing to pypi everytime, I thought the release feature on GitHub was a suitable mechanism for deploying to pypi since messing up wouldn't have involved rewriting git history.

I'm more than happy to change this to every non-prerelease version pushing to pypi automatically, but it felt like at the time we wanted to have some sort of manual control and/or QA process.

tyler-jachetta commented 3 years ago

^ certainly a reason :)

Should I be hitting the release button here, or should I leave that to my betters? (and should i hit release for 1.0.11, since that's not at pypi, or should I skip it?

otakup0pe commented 3 years ago

Instead, I proposed moving to versioning on every push to this repo and only relying on hints as modifiers from a default bump level (patch). Instead of pushing to pypi everytime, I thought the release feature on GitHub was a suitable mechanism for deploying to pypi since messing up wouldn't have involved rewriting git history.

Oof I completely forgot about this. I guess I should enable the wiki for this project, or do we want to add more focused markdown docs straight into the repo?

Should I be hitting the release button here, or should I leave that to my betters? (and should i hit release for 1.0.11, since that's not at pypi, or should I skip it?

Go for it.

mjuarez commented 3 years ago

Oof I completely forgot about this. I guess I should enable the wiki for this project, or do we want to add more focused markdown docs straight into the repo?

Only reason I'm thinking wiki is that the instructions would be irrelevant for folks forking the repo or browsing source locally. It's more GitHub specific/maintainer policy specific