Comments (4)
Could help. But I immediately think of questions then.
- Should we do this before release or before release? Preferably the first. But if someone only calls release, then you do want to check it.
- Such code should work with git, mercurial, bazaar and subversion.
- Do we make this a new question? "Shall we update the local branch from the remote? [Y/n]?"
- Do we git pull the changes and apply them?
- Or do we git fetch and only detect changes? Do we then offer to merge them, or do we quit with an error?
- If there are changes, then the user should view them before going on with the release. Do we show the changes or do we quit so the user can inspect?
- What if the user has made local changes (fixed a typo in the readme). Does that give a false positive for the local not being up to date?
So a lot of questions, although that does not mean we should not do this.
On the other hand: when pushing fails, you can fix it up, and then make a new release.
BTW, this could be done in an extension. See the entrypoints documentation. Register an extension for the zest.releaser.prereleaser.before
(or maybe the zest.releaser.releaser.before
) entry point and maybe start simply by doing a git pull
there.
from zest.releaser.
Should we do this before release or before release?
My workflow is usually the following:
prerelease
and open a pull-request- gets approved and merged (can be days)
git co master && git pull
(<-- this is where I forgot that the branch is now calledmain
)release && postrelease
(<-- this is where a busted version was published on pypi and I realized it in postrelease)
Do we make this a new question? "Shall we update the local branch from the remote? [Y/n]?"
Do we git pull the changes and apply them?
Or do we git fetch and only detect changes? Do we then offer to merge them, or do we quit with an error?
Detecting that the local branch is behind is already something. I don't think we should try to automate anything at this point. Error and exit.
What if the user has made local changes (fixed a typo in the readme). Does that give a false positive for the local not being up to date?
I don't think we should introspect too much, just that local is behind remote and not the opposite. Something like git remote update && git status -uno
maybe? (don't know about other SVCs)
Thanks for pointing out the extension part!
from zest.releaser.
My workflow is simply to do fullrelease
. There the only reasonable moment to do this check, is before the prerelease phase. So our workflows may differ too much for this to be usefully added to zest.releaser.
Well, technically we could do it before prerelease, then add a marker in the data dictionary that we keep, and then before release check if the marker is there. If so, then we do nothing. If not, then we do the check.
I don't plan on working on this currently. We could consider a pull request. But maybe easiest and better to do this in an extension. That also means you need not worry about mercurial and others.
from zest.releaser.
Thanks for your feedback, and for the tool of course! I assume we can close then.
from zest.releaser.
Related Issues (20)
- Unexpected `prerelease` behaviour with Changelog containing markdown links HOT 2
- Documentation: hook_package_dir en entrypoints section.
- support [tool:zest.releaser] in setup.cfg HOT 2
- support pep621 HOT 4
- Future plans for zest.releaser HOT 4
- Prefixing git tags with a "v" HOT 2
- Check version for PEP440 HOT 3
- bumprelease functionality HOT 6
- zest.releaser with plone.releaser breaks when not in a buildout.coredev environment HOT 3
- Failed git push does not fail release HOT 6
- Possibility to add prefix to commit messages HOT 6
- ValueError: binary mode doesn't take an encoding argument HOT 9
- fullrelease: error: no such option: --no-input HOT 8
- sdist is missing tox.ini HOT 1
- tests fails with non-GNU ls HOT 4
- testing: the following arguments are required: message HOT 1
- testing: bumpversion and postrelease tests fails HOT 3
- Always create wheels, when possible HOT 2
- Warn/ask to verify for deprecation notices when making a major release HOT 4
- get_last_tag can fail with recent setuptools HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from zest.releaser.