-
-
Notifications
You must be signed in to change notification settings - Fork 360
Suggestion to create regular tagged commits #449
Comments
Thanks for the suggestion. I'm sure we can tag releases when we have something folks feel is worth tagging. At this point, everyone has been iterating on the latest code and I can't recall anyone needing to jump back to an earlier copy, which I assume they could do using a commit hash in the logs. Is there any guidance on when to start tagging 0.1.0 release, or some such. Also, the out of date schema can be seen in the CONTRIBUTING.md under the Database section by expanding a collapsed area. I have PR #448 open to clean up the CONTRIBUTING.md so if you have time to contribute, then feel free to run through this copy and suggest improvements. It now breaks Running the Application into Docker-mode and Manual-mode, since we have a mix of how contributors are running their dev environment. Also, we could use help getting a schema that's auto updated. Schemaspy is the suggested direction and we need someone with experience to make that happen on #54. |
Also, here's an out of date Schemaspy schema from #54 (comment) |
Chapter-commit-tag-proposal
Tag syntax options
Benefits
Comparisons
For reference look at the tag history for 2020Then look foward at 2021, 2022, 2023, 2024Conclusion
|
Thanks for the well described options. I'd see the tags being more useful once we're into or approaching an alpha. Right now the app is going to be in flux and we don't really have stable points. Though, if you feel we should start tagging at reasonably stable points, like with semver, then that's what I've most familiar with. At this point, we need commits more than tags. However, if you want to lead the charge on a tags system, then we'd be glad to have your leadership on this task. |
@allella I see what you mean about commits, a tag only has significant meaning the project participants assign to it. Here is an example of suggested meanings assigned to a tag. Quarterly milestone goalsGeneric[ ] Update chapter version numbers in code to match the pending milestone version [ ] Security version updates
[ ] Update dependency versions [ ] Remove unused packages [ ] No lint errors [ ] No test failures [ ] Following
[ ] Create next project milestone Specific features[ ] Add CI/CD build pipeline test badge to the README [ ] Add a branch named WorkflowThe workflow might look something like this. About three weeks before the quarterly milestone some trusty volunteer would fork and then create a branch called for example RC-2021.Q2.00. There would be no more features added to this RC branch. The proposed version upgrades would be added and linted, tested and built as suggested in the goals above. When all the lints, automated and manual tests are completed, then the last commit on that branch would be tagged with the name for example 2021.Q2.00 and merged with with the branch stable and a pull request made to the master repository. Finally the branch stable would be merged back into master, to capture security and dependency updates, ( hmm... as well as the latest stable version number in the project code, that would need to be updated to reflect the in-flux master branch. ) and a pull request would be made to the master repository as well. At this point a video could me made to capture project highlights in the stable branch. To maintain project momentum, feature changes would still be allowed on the master branch, which would continue to be the default branch. |
Thanks again for the detailed suggestions. I'm still of the mind this is all best for seeding a future conversation once we have something worth tagging. We're still a good 6 months from even having something we might share with testers. As it is, progress is slow and until we get an app that renders and looks useful, I'm not sure we'll have much need to tag it as a relatively stable point in time. Also, since this is not actively deployed, I'm imagining we can bring all the packages up to date for security and features as we get closer to identify a taggable point. We expect Fran to be active in the next 1-2 weeks and I'm sure he'll have thoughts and much of the progress has been dependent on his commits. |
A view from the peanut gallery. I have not been able to contribute much, however I have regularly followed the commentary and issues. One comment that worries me has been repeated a couple of times is something like "when we release our MVP at 1.0". The way I literally see the commit network on Github is as a series of releases to the public. The project is open to anyone who wants to look at or clone the code to try it. Whether we like to admit it or not, it is already released.
A few weeks ago, I tried to find the data definition language (DDL) feature from early on in the project and after hunting and pecking through each commit I realized that I was not going to find it in a reasonable amount of time.
This example of my search highlights a lack of commit strategy I think could create potential headaches for the project developers going forward, which is why I am suggesting that on some schedule a project admin tags a commit on master and gives it some responsible version name, number or date or whatever. That way Github will ball up everything in the project and make a zip file snapshot of the project to be readily inspected, tested, shared etc.
Current discussions about bumping to the next major version of nodejs is another example of when this project could reasonably be expected to have a tagged commit noting the major changes.
The text was updated successfully, but these errors were encountered: