I'm currently struggling with automatic merges of a semantic versioned node project. In my current setup I have to maintain multiple older (minor) versions of the applications. To ensure that bug fixes in older versions are also applied to newer versions I'm using release branches in combination with bit buckets feature of auto merging. It works great apart from permanent auto merge conflicts with the version of the application that has to be stored in the package.json. Each time an auto merge happens there is a version conflict with the newer release versions.
Is there any way to avoid those merge conflicts? I fiddled around with a custom merging driver (https://gist.github.com/jphaas/ad7823b3469aac112a52), it kind of works but in my opinion there should be an easier solution like storing the version in a dedicated file (e.g .npmversion) and using build in merge drivers.
Related
github.com/hyperledger/fabric makes use of github.com/hyperledger/fabric-protos-go repo as a dependency module to setup gRPC communication between nodes. These fabric-protos-go files are generated by .proto of github.com/hyperledger/fabric-protos repo.
I have cloned github.com/hyperledger/fabric Tag:v2.4.7 repo and making some updates on it. I need to generate some go structs to use by defining new message in .proto files.
This fabric-v2.4.7 depends on github.com/hyperledger/fabric-protos-go v0.0.0-20220315113721-7dc293e117f7 as per the go.mod
But I am not able to identify which version of fabric-protos led to generation this fabric-protos-go v0.0.0-20220315113721-7dc293e117f7. Because if I clone the the latest version of fabric-protos repo to generate go files and use as dependency its throwing many incompatibility errors.
Please let me know how can I determine which version of fabric-protos-go and fabric-protos were used in a specific fabric tag.
This documentation page for fabric-protos mentions which versions of the protocol buffer bindings correspond to which Fabric versions:
https://hyperledger.github.io/fabric-protos/
The protocol buffer definition files are in branches of the fabric-protos repository, named the same as the versions in the documentation page above. Currently the main branch contains the definitions for Fabric v3 (the v0.3.x versions of the published bindings).
If you are making modifications, you should just pick the HEAD (latest commit) of the appropriate branch on which to base your change. Avoid making breaking changes. Changes will also need to be applied to any more recent versions (branches) so compatibility is maintained going forwards. A good strategy if you actually come to push changes to the repository is probably to raise a pull request for the main branch first, then cherry-pick changes back to as many earlier version branches as you need.
I'm maintaining some large NodeJS applications(micro-services, apps), which consume many(at least 100+) dependencies.
Updating those dependencies to fix a security vulnerability forces me to spend valuable development time.
Is there any way to automate package updates across repositories?
We're using GitLab for SCM.
I had thought of some options like:
Separating out core dependencies into a base level library.
Maintain a repository that specifies security-cleared dependency versions and repositories to be updated whenever the cleared list changes.
Any additional suggestions/examples?
Just to help shortlist approaches mentioned in the question:
1. Separating core dependencies into a "Core" library.
This can reduce the number of updates. But the libraries based on "Core" sill still have their own dependencies, which may be prone to vulnerabilities and the update cycle must be repeated for them manually. This approach just procrastinate the manual updates.
2. Maintain a repository that specifies security-cleared dependency versions and repositories to be updated whenever the cleared list changes.
Couple of options here:
Article on automating via pipeline scripts
GitHub: Use next-update + Hub CLI
GitLab: Use next-update + Lab CLI
Implement dependabot-core(GitHub) or dependabot-gitlab(GitLab)
Implement renovate.
We build our installs\releases using Install Shield. I have come to a situation where we have a patch that cannot be upgraded by a release with a higher version number, that is missing components included in the patch.
After releasing a full minor release (i.e. 7.2.0) we released a patch on a previous full minor release (i.e. 7.1.12).
The Patch 7.1.12 had files and components added that do not exist in 7.2.0. The patch is not uninstallable.
It is now impossible to upgrade 7.1.12 to 7.2.0 because of the missing components. Some customers specifically want to upgrade to 7.2.0 and not a later version (7.3.0) where the components can be added to fix the issue.
Short of uninstalling 7.1.12 and then installing 7.2.0 I couldn’t find any solution to fix.
Is there any way around this? Can we build a 7.1.13 as a bridge to somehow fix the mistake. Or use an argument when installing 7.2.0 to get around this.
I looked around the registry and I am trying to figure out if it is possible to remove the components through the registry.
I tried deleting the component entries in the registry. that didn't do it.
If I delete the product entry in the registry that works - but it must be overkill.
I also tried deleting the patch msi from C:\Windows\Installer but that didn't do it.
There must still be a way to unlink the component from the feature in the registry without deleting the entire product.
It sounds like you're trying to do a series of Minor Upgrades, with at least 7.1.12 delivered as a patch. Using minor upgrades imposes various limitations; anything that requires you to Change the Product Code must be avoided. In your case, note that adding components is allowed, but not the reverse:
The update can add a new component to a new or an existing feature.
The product code must be changed if any of the following are true for the update:
A component is removed from an existing feature.
In short, any modifications to the feature-component tree, other than the addition of new ones, is going to require changing the product code, and thus a Major Upgrade. Major upgrades perform an uninstallation behind the scenes, and thus are less restrictive about the changes they are allowed to deliver.
You have two options:
Use a major upgrade, or some other means of uninstalling the old installation before installing the new version. If possible, this is what I would recommend. Using minor upgrades often adds more difficulty than benefit (though your needs may differ).
Maintain the new components in your newer versions. Note that you do not necessarily have to maintain the resources within them:
The update can add, remove, or modify the files, registry keys, or shortcuts of components that are not shared by two or more features.
But you will have to make additional changes to account for the changes to the resources. In your case, this probably will require additions to the RemoveFile table, and may be best served by "puncture component" pattern.
Spelunking through the registry for a workaround that modifies Windows Installer's bookkeeping is a bad idea. It may work, it may appear to work, or it may not work at all. In no case is it supported.
If both versions 7.1.12 and 7.2.0 are already publicly released, you're in a rough spot. I think your best bet there is to re-release 7.2.0 with a new product code and version, e.g. a 7.2.1 major upgrade. You can advise your end users that those already at 7.2.0 don't need to install it.
I am analyzing the monorepo strategy for some of my framework node modules / libraries that are currently part of different repos. I have around two dozen node modules / libraries and not all of them are used by a single application. Few applications just use a single node module / library whereas others use 5+ of them. I am using a semver for these modules.
If i move to monorepo, what would be the best GIT branching strategy in the following scenario
I planned to support only the two major versions of a module at any time. (latest & latest -1). Latest should have all enhancements & breaking changes. latest - 1 is to support bug fixes of previous release. What would be the best branching model for this scenario ? Note, another developer in my team may modify a different module for bug fixing or he / she may add new enhancements to a module. How do we separate our changes inside a single repo ? what is a proven branching model in this scenario
Here's my project development process:
feature/feature1
feature/feature2
feature/etc..
master
production
I develop my features on the features branches, when I have finished with a branch, I merge it on master and delete it via github ui. CircleCI detect the merge and deploy the master on a staging server.
Later I merge manually the master branch onto the production one, and CircleCI deploy to my productions server.
I would like my package.json version to bump each time I merge a feature branch to the master branch (via github UI). But I have no idea if
Github allow to do so (if yes please can you explain to me?)
It's a good process
I'm aware I could do it via npm version command when I merge master onto production, but I do need the version to be updated on the master automatically when I merge a branch into it.
Don't hesitate to criticize my way to proceed and tell me yours. :)
Thank you
I don't think Github offers any such feature. But there are some grunt modules that do this during build time. You could probably script this or have a make file that does this for you as well.
I don't think this is good way of versioning. After you are done with a feature, you have to decide if the changes you have made are minor or major. Some times you might commit breaking changes. Just incrementing the version number form 1.0.1 to 1.0.2 or say 1.1.0 to 1.1.1 (every time) will not convey the magnitude of these changes. Best Practice: Software Versioning
The best practices for versioning are already covered here.
We manage versioning manually where I work. Before each release we create a tag (v1.0.3, v1.1.4..etc) and then create a release on Github. In the description of the release we put all new commits. Going through the commit message gives us a good idea of the changes that were made. If the changes only involve bug fixes and minor feature additions we will increment the minor number ie. 1.2.1 to 1.2.2.
If a major new feature is added, we increment the major version number ie. 1.2.2 to 1.3.0. When we add many breaking changes we go from 1.3.0 to 2.0.0.
Sometimes we are loose with versioning. Our API is not public and the only reason we use versioning is for deploying and for rolling back. If you are expecting to make you work open source and or expecting to make your work available through some kind of package manager, like say npm, you should follow semver versioning strictly.