I created an Angular project using angular-cli and pushed it to GitHub. I then created a new branch and updated packages, installed standard-version and ran npm run release -- --first-release as instructed. I then pushed the whole into a new branch on GitHub, created a pull request, squashed and merged onto master, pulled back into local master, and ran standard-version again finally followed by git push --follow-tags origin master. Here's the state on GitHub:
All notes that I wrote in the pull request body are not visible in the changelog file, and they are obviously not in the chore(release) generated by standard-version. Why?
They are also not written within the Releases tabs at all, even though I can see the released tags there.
Should I have made the version 1.0.0 in packages.json before starting in order to adhere to semantic versioning?
What am I doing wrong?
You're not doing anything wrong. chore doesn't show up in CHANGELOG.md (see: https://github.com/conventional-changelog/standard-version/issues/135)
To have release notes uploaded, you will to use something like https://github.com/conventional-changelog/conventional-github-releaser
It's up to you where to start. Generally, when labeled 0.x, the project is still unstable and will go through vast API changes. When the project becomes stable, bump the major to 1.x and adhere to semver.
Related
I recently created an extension and I am trying to set up a workflow to automatically publish the extension to the VSCode marketplace when I see fit.
I have read the official article which only shows fractions of the final set up and which also seems a little outdated. Following that and copying from misc. repos on Github, I have patched together a semi-working solution. Yet, the workflow is really odd.
It seems like the tutorial is suggesting you try to run a vsce publish when a new tag has been pushed or a release has been created/published. But here is what that looks like:
Make a commit(s) with new code/features you want to add to the extension.
Change package.json manually to update the version number.
Tag the commit manually with the same version number.
Push commit and tag.
(make a release manually on Github to have consistency between tags and published extension version and to trigger eventual action)
Github action is executed and hopefully succeeds, otherwise you will have to redo a bunch of above steps.
The above workflow is not optimal as it requires you to enter the version number about 3-4 times. This can be improved somewhat.
Make a commit(s) with new code/features you want to add to the extension.
Run vsce package <version> to create a new commit with a new tag and also update package.json in one command.
Push commit and tag.
(make a release manually on Github to have consistency between tags and published extension version)
Github action executed vsce publish which almost certain to succeed since vsce package <version> already succeeded previously.
This scenario is better but still has some problems:
The Github Action will need to listen to a new tag push.
Could it also create a release automatically?
Is it common practice to always create a Github release from a tag?
Step 2 requires you to build the project to a .vsix file.
Can this be prevented?
We could instead do this on Github through and action. But what would we listen to to trigger this action? We need a version number, but it can not come from a tag since vsce package <version> creates a new tag and updated the pacakge.json for us.
What is the optimal workflow to make this process as painless as possible?
Because we've done some rearranging of our documentation setup, I have two separate read the docs projects which I need to build from the same GitHub repo. One of them is brand new, and the other used to be pointed to the old repo.
I have set up a webhook on each project, and added both these webhooks to the repo.
The problem is that in the project that used to be pointed to the old repo, the stable build is still associated with the SHA of the latest release on the old repo, which does not exist in the new repo. This causes the stable build to fail.
One other thing I hope to solve, when activating some of the new versions (which used to exist in the old repo) an "_a" is added to then of the published version name, even though there are not multiple publishable versions with the same name.
I'm wondering: is it possible to completely refresh all of the RTD-detected versions and tags? I think doing so would solve both these issues.
I've tried "wiping" the builds but that doesn't help, I have read the RTD docs on versions many times, and I've triggered new push events from github (which are sent and received successfully) but still can't make any progress.
The best way to solve this turned out to be just recreating the RTD projects. If anyone else comes across this issue, you could check out the ticket I made on the RTD repo https://github.com/rtfd/readthedocs.org/issues/3763.
Trigger a Build on any of the existing versions that RTD knows about. After that build job starts the Versions list will be updated from the git repo.
I have my own PHP/Composer repo on GitHub and have it published on packagist.org. Everything is fine so far. The Webservice is correctly configured and several versions have already been published.
But now I have the problem that when I try to publish a new version, it does not "end up" on packagist. Interestingly, packagist shows me (among older versions/tags) a version/tag "dev-master". After I pushed my latest changes to GitHub, created a tag/release on GitHub, and used "update" on the Packagist interface, this "dev-master" points to the latest commit on GitHub, but the new tag does not show up. Hence, when using ./composer update in a project, nothing is updated at all.
Here is step-by-step what I do:
Update and test my code.
push it to the master branch of the repo at GitHub (master is the only branch here a.t.m.)
update composer.json's "version" attribute to reflect the tag I am going to use for the next release
create a new tag via the "draft new release" function in github (e.g. "5.6.7")
go to packagist and click "update" in the repo.
Funny thing is, sometimes it works, sometimes not.
PS: Seems NOT to be an issue of delay. WHEN it worked, the new version was visible and installable within seconds. Otherwise, also waiting for several hours didnt fix the problem. Also, the hash of the latest commit from github is visible for "dev-master" immediately after I use "update" in Packagist.
Can anyone please tell be what I am doing wrong here?
I'm editing one of my open-source projects on GitHub and I want to replace link (pointing to a demo) in README.md.
Do I have to update library version every time I introduce some minor changes to the README file or documentation (without any actual code changes)?
What is the community accepted practice?
If it's important, I'm using Bower to distribute my package and SemVer as a versioning system.
The README file is part of your codebase. It should describe the current (= in current commit) state of the code. A developer might read it outside GitHub's environment, e.g. from the node_modules directory on their hard drive, expecting it is up to date.
Therefore I would recommend to release a new version when the README changes.
It will usually result in just a patch number increase. But remember that when marking something as deprecated one must release a new minor version (paragraph 7 in SemVer v2.0.0).
If you plan to do really a lot of changes there are two ways to avoid releasing too often:
Make changes in a branch. Merge to master here and there, release a new patch version.
Move the documentation (or a part of it) somewhere else. GitHub Wiki or a simple webpage, e.g. using GitHub Pages, could come in handy.
You could include, as library version, the content of of git describe --all --long, as described in How can I get the Git build number and embed it in a file? (using git describe).
That way, you get the latest tag, plus the number of (small) commits you did since that tag.
That means:
you don't have to put a new tag if you don't want to
but you still keep an exact reference the the version of your repo which was used for delivering your app.
I try to understand the right approach for managing hotfixes with TFS /source-control.
Say I have a small project to contains only two file (app.js and util.js). Both files are under source control (Team Foundation Server).
Assuming I applied two weeks ago a label that indicates the "milestone-1" that was deployed to the server. Since then I applied several other modifications (extended app.js and added another files).
Today I found a bug so I get the version with the label "milestone-1" from the server, modify the util.js and deploy this version to the server. The goal is that on the server only the version "milestone-1" including the hotfix-1 is deployed but not the modification I applied the last two weeks.
The question is: How /where do I check-in the hotfix to the TFS? Because I might find another bug tomorrow so I have to get the version "milestone-1" and the hotfix-1 base base for appling the second hotfix.
Is there a way to check-in a version of my code into the TFS that "sits" between label "milestone-1" and my latest version?
With branching and merging!
We have the following development cycle:
The initial project is created, permissions assigned, and imported in to TFS under branch name of "Main".
Because this is the initial iteration of development, we branch "Dev" from main, and that's where the developers work. Note at this point there is no official release.
When development is complete, it is merged back in to Main. No Dev work happens on the Main branch.
We branch "Release" from main, and that is the point at which the code is actually deployed, and version numbers are updated.
Ok, so, further down the line, we have to make some amendments. Once again, "Main" is branched out again and the development work continues down the Dev Branch. All is well. Then a user reports a bug that needs fixing, and it needs fixing fast. But we're half-way through our other development!! What to do?
At this point, we branch from main again. We'll call it "HotFix". The bug is fixed, and then HotFix is merged back in to main. We can then merge it in to our release branch, and the update is sent out. Our current dev work is not interrupted, and none of the work we have been doing up to this point exists on Main).
We finally finish our dev work, and we merge that back in to the main branch, and then in to release. Because our Hotfix branch got merged in to main, our new development work also contains the hotfix we did on the fly earlier.
You should use branching. Check out the "Rangers'" guidance.
I have successfully used the Advanced Branch Plan in the past, but you can customize it to your needs. You need to be disciplined with branching, merging, checking in, etc. Also consider shelvesets for code changes that aren't ready to be committed even to the DEV branch.
http://vsarbranchingguide.codeplex.com/
Let me know if you want more information.