Right now, my approach to releases is pretty...ill-defined. I tend to tag a release when I feel the code has both made significant strides since the last release and the code is relatively stable.
Anybody who purports their releases are bug-free is either dishonest to their clients or to themselves, so bug-free is not the goal. However, a few dumb mistakes keep getting made:
version numbers aren't updated in package headers
documentation isn't up-to-date
released functionality has unreleased dependencies
I'd propose a makefile target is created that will prepare the worktree for a given release. This phony target could either take the role of a linter -- reporting errors to be fixed manually -- or maybe something more.
Right now, my approach to releases is pretty...ill-defined. I tend to tag a release when I feel the code has both made significant strides since the last release and the code is relatively stable.
Anybody who purports their releases are bug-free is either dishonest to their clients or to themselves, so bug-free is not the goal. However, a few dumb mistakes keep getting made:
I'd propose a makefile target is created that will prepare the worktree for a given release. This phony target could either take the role of a linter -- reporting errors to be fixed manually -- or maybe something more.
Related to #219.