search

3YOURMIND / django-add-default-value

This django Migration Operation can be used to transfer a Fields default value to the database scheme.
Apache License 2.0
138 stars 20 forks source link

Integrate travis #9

Open ghost opened 5 years ago

ghost commented 5 years ago

Now that we have tests via tox, we can integrate Travis

igeligel commented 5 years ago

It would be good to have some requirements here:

What do you think?

ghost commented 5 years ago

"configuration is created" should be:

The .travis.yml file should do the following:

Will have to see about when to run tests.

I don't believe in automatic publishing, packaging maybe, but not publishing, so I can test the package locally and if there's an oversight can either move tags, or bump again. But don't make a package hit PyPy for no reason - downstream are stuck with it for at least an hour.

Otherwise, yes.

igeligel commented 5 years ago

You can have different build stages to differentiate between environments: https://docs.travis-ci.com/user/build-stages/

I don't believe in automatic publishing

It just gives you advantages if you have good tests in place. The pipeline could run a diff on the version in the setup.py and then automatically bundle and publish. Clients can lock the version if they want. It just improves the developer experience for this package a lot. Also check out the principle: Release early, release often: https://en.wikipedia.org/wiki/Release_early,_release_often

If you need to test it locally to find issues, you are not fighting the root problem here which is missing tests then.

ghost commented 5 years ago

If you need to test it locally to find issues, you are not fighting the root problem here which is missing tests then.

You're assuming the reason to reroll a release are based on code. I'm not. If I can clean up human language, add emphasis to certain passages or highlight new features in release notes, I see it as improvement of that release. And if you keep that "for next time", you know it's not going to happen. Anyway, let's see if releasing becomes a flawless endavour in the future and then we can add it to possiblities. Right now, I don't see it as a requirement for 0.5 (See roadmap).

igeligel commented 5 years ago

releases are based on code [...] I'm not

If you follow semantic versioning, which you should, it is.

Every bugfix is an increase in the patch version, every non-breaking feature is a minor version upgrade, every breaking change is a major version. Combining this with git tagging gives you the opportunity to easily version your package and make it available really easy.

Also see how easy it is: https://circleci.com/blog/continuously-deploying-python-packages-to-pypi-with-circleci/ (using circle ci but should be similar to travis).

Really, if people do not push for semver and automatic releases then humans will make mistakes, which is granted. In the Node.js community this is a bigger problem because you rely more on external packages and solutions got created like https://github.com/semantic-release/semantic-release#readme to actually release code automatically. If you have some time lookup the resources here https://semantic-release.gitbook.io/semantic-release/support/resources and then you might understand why this topic should be important.

ghost commented 5 years ago

Please don't assume lack of knowledge on my part, just because you don't agree with a well-informed choice.