I have a personal bitkeeper repository and would like the version numbers to change from 1.xxx to 2.xxx.
My usage is a perl library and I have made major changes to the calling sequence and would like the SCCS strings that automatically get updated to reflect the new sequence. This way the use Module VERSION method will easily determine which calling sequence without having to specify 1.32 is the old one and 1.33 is the new one, for example.
BitKeeper doesn't support changing the major number (or release number in SCCS lingo). Also note that coding logic that depends on revision numbers is fraught with peril as they can be unstable (e.g. what is revision 1.33 on your tree might be moved to revision 1.28.1.1 once you push).
Related
Are #babel/runtime and #babel/plugin-transform-runtime supposed to be on the same version (e.g. both 7.2.0 exactly)? Or can I (as a library author) specify #babel/runtime dependency as ^7.0.0, whilst having the latest #babel/plugin-transform-runtime?
I'm aware that during the beta versions of Babel 7, there was a breaking change in beta.56 (see https://stackoverflow.com/a/51686837/2148762), but I'm guessing this should no longer be the case with the current stable version?
The reason I ask this is I'd ideally want the helpers from #babel/runtime to be shared across different packages, and to me leaving the version range open seems like a good idea. But at the same time, I'm not sure how low I should go (^7.0.0 or ^7.2.0), and whether there's an implicit contract between #babel/runtime and #babel/plugin-transform-runtime with regards to version numbers.
By default, #babel/plugin-transform-runtime is only allowed to output references to #babel/runtime that work on ^7.0.0 because it does not know what version you'd otherwise want to use, and doing anything else would cause lots of issues for users. This means that what you want to do is safe. The downside of this is that, if we add new helpers moving forward, your code would not be able to take advantage of the #babel/runtime version of them (because you might still be using a #babel/runtime version that doesn't have them.
Users can specify the version in the arguments for the transform, if you want to specifically make use of helpers that may have been added to Babel since 7.0.0, e.g.
{
"plugins": [
["#babel/plugin-transform-runtime", { version: "^7.2.0" }],
]
}
would then require you to have "#babel/runtime": "^7.2.0" in your package.json.
For instance, since support for the newer decorators proposal didn't land until Babel 7.1.5, if you use transform-runtime and non-legacy decorators, the decorators helper will still be inserted into every file where you use decorators, instead of importing it from #babel/runtime. To get the shared helper, you need to specify version: "^7.1.5" in your options for transform-runtime.
Can I (as a library author) specify #babel/runtime dependency as ^7.0.0, whilst having the latest #babel/plugin-transform-runtime?
Yes, this is safe.
I'm guessing this should no longer be the case with the current stable version?
Correct, that issue was because people failed to take the beta versioning into account.
Previous history: The last couple of years I used SVN. Releasing a new version of a software project included following steps:
creating a branch for the new release: /repo/branches/0.1
getting the code into a release-worthy state there
creating a tag for a release candidate: /repo/tags/0.1-RC1
creating branch for RC1 to fix bugs: /repo/branches/0.1-RC1
creating tag for a new release candidate: /repo/tags/0.1-RC2
{...}
creating a tag for v0.1 from the last RC: /repo/tags/0.1
merging 0.1 into trunk
As far as I got Mercurial sees branches and tags slightly different than SVN and this finally leads to my question:
Do I create branches (and tags) for releases? And if not: What else wants Mercurial me doing to archive something similar to the described development pattern/cycle?
You can easily keep using this method. I'm not sure what you'd need a separate RC1 branch for, but I guess there are good reasons.
There is a bit of an annoyance in the way tags are stored in Mercurial, which is a versioned file listing them one by one. As a result tag creation constitutes a changeset. You should strive to keep all such tag-creating changesets on one branch, or you will get merge conflicts (which are easily resolved, but annoying nonetheless).
You can use old workflow, but:
Branch per release really needed (in any SCM) only if you have to maintain some amount (>1) of releases in production at the same time, gor single maintained release branches-tree not needed
I see a lot of (rather complex) projects, which use two-branches method ("Stable" with mergesets only and tags + "Devel" for every-day development (short-term branch-per-task are also possible, but it's more question of tastes and habits, than "a must")
I don't think I even want to see it. Why do others find it so important ?
Isn't Base, Target enough for the "resolving conflicts" aka Merge tool window. What am I missing ? Are people really that bothered about the version before Base i.e. Source ?
It seems you have a fundamental misunderstanding about what each of the versions are. When you merge two branches, almost always you want to keep changes from both branches. Base is the latest common ancestor of the two branches. Base->Source shows what was changed in the branch you're merging from, and Base->Target shows what was changed in the branch you're merging to. To properly resolve a conflict, you need to know what was changed in each branch.
(Some documentation for p4merge at p4 docs - Merging Files)
When working with a merge conflict, there are four parts to it:
The common ancestor that both branches changed
Their changes (source)
Your changes (target)
The final result
(You may have an old version of p4merge - the docs show a different wording that may clear up the confusion)
The 'source' is not the revision before, but rather the incoming changes from the merge that someone else made.
Ignoring either your changes or their changes is a possible conflict resolution - many have that as a default "merge, handle conflicts by use mine." However, this has the distinct possibility of causing regressions of functionality introduced by the other branch (or worse, removing code the other branch is expecting).
For a given code block with a conflict, both your changes and their changes are important, and the ancestor of the two gives the appropriate context for what the change was.
I have a local copy of a solution. It is bound to TFS
Is possible to derive the current change set information from the local file system without doing a call to the server?
Here is a workaround, if you can use the Revision number in the [assembly: AssemblyFileVersion("1.0.0.RevisionNumber")] you could set the change set information there.
Aligning assembly version numbers with TFS Buildnumber, this way each time you build, each projects AssemblyInfo.cs would contain the change set info. Admittedly this would be project-wide, not file specific.
After some more research I found this thread and its seems very close:
TFS and msbuild version number with last changeset
This is not an answer, but rather a long comment. That's why I've marked it as CW.
Here's a thought experiment:
Pick a time, any time. Determine the latest changeset as of that time. Call it "cs".
How do you know that there isn't a later changeset checked in just seconds after you figured out "cs"?
Without connectivity to the server, there can be no simultaneity.
I have a version control system (e.g. Subversion) and now I'd like to set up a build process. Now I have to create a version number and insert it into the system. But where does the version number come from and get into? Assume I want to use this common <major>.<minor>.<bugfix/revision> scheme. Should I pass a number to the build script? Or should I pass arguments like increaseMajor, increaseMinor, increaseRevision? Or would you recommend to create a branch with the number which will be detected by the build script?
I could imagine that the major and minor version number have to be put in manually somewhere. The revision number could be increased automaically. But still I don't know where I would place the major and minor number.
In my case I have some php files that I would like to zip, but before I have to insert some version numbers into php file.
I have edited this post to try to make my request clearer:
I do not use Subversion, that was just an example. And I don't want to discuss the version number scheme.
Imagine I want to create version 3.5.0 or 3.5.1. Would I pass this version number to a build script? Would the script create the branch in the repository with this number or would it expect that someone has already created this branch? Manually? Or would the build script look for name of the branch (e.g. '3.5.1) and use it for further things? And does the version number come from my brain or is it automatically created (I guess the major/minor number it comes from my little brain and revision number is created)? Or would you place the number into a file that may gets inserted into the repository?
I guess if would use a release management tool I would insert the version number there. But I don't use one yet.
For subversion, either take the global revision number and use that as "build" number or, even better, don't rely on it at all and manage versions with tags and/or branches. The main problem with the global revision is exactly that, it is global to the repo. It will increase even though some parts of the repo don't change.
Completely disassociate versions from the repo's revisions is IMHO better. You have tags, use them.
agreed with all previous on the use of branches and tags. Additionaly the branch names and tag names can be incorporated into a build process w/ some clever scripting.
The only tidbit I wish to add is that you should sneak your SVN revision into every build. Sometimes it's easily to get back to a certain point w/ the revision instead of knowing the tag or branch. 99% the tag/branch is good enough, but the revision is great for incremental/internal/continous/test builds.
All branches should be created manually. The build script should work off a tag and/or branch, starting with checking it out (or may be updating it). As part of teh build process, it's a good idea to create a tag on the exact snapshot that gets built.
You would normally have build number and a version. Build number can be incremented automatically and checked into version control as part of the build (except for tag-based build, where the build number has to stay outside of repository - another reason to avoid tag-based builds).
Version is usually stored in a file that you update manually once per release cycle. It's checked into th eright branch and then left alone. For example, the mainline would have version = "3" in its file, the first revision on release branch would have version = "3.5", and if a patch release becomes needed, you branch that off your release branch and check in version = "3.5.1"
The revision in svn or any other version control system is not the same thing as your product release number (or even your build number).
There are any number of ways that you can enforce the version number. Commonly in subversion you can create a branch (or tag, they are essentially the same thing) for a build and if this is a release version you create a tag for this eg svn://my-repo/releases/1.0.0
You could either pass a parameter into your build script to get the code and use that as the build number, or have a directory which your build script used, and svn switch this to the branch that you wanted to build, the script could use svn info to determine what version it was building.
x.y.i.j
Where x - Major version, y - Minor version, i - Build number, j - Revision number
Major version increments on major changes (new architecture, new UI, etc)
Minor version increments on minor changes (performance improvement, major bug fixing, etc),
Build number increments everytime you makes a public release.
Revision number increments everytime you commits changes to the project source tree.
I prefer to point 0 as revision number into AssemblyInfo.cs and point the real number in the name of release package (foo-1.1.7.110-source.zip)