I tried running gitVersion on extremely old and complicated codebase that was migrated with git-tfs. I do get results in most branches but they are incorrect.
How do I get started with existing repositories?
How do I debug the results so I know what contributed to the final output?
Can some branches be ignored because they used are incorrectly attributing a larger number?
Sorry to hear that you are having issues using GitVersion.
Not sure what you mean here, can you elaborate?
The GitVersion log output is quite verbose, as you can see here as an example. It walks you through what base versions it can locate, and from there, how it asserted the final version number.
You might want to take a look at the commits-before configuration option which might help with an older code base that wasn't sticking to conventions, and a result, ignore the prior commit history, and start versioning a fresh.
Related
I am confused about how next-version property works. I read the official documentation, it just a two line "only server as base version". I assume it will bump to the version I set on the next commit. But apparently it does not work like that. It seem like it adding current version number with the version number in the next-version, but it is not quite like that. Hope some one can explain it further. Thank you.
next-version is described in the documentation as:
Allows you to bump the next version explicitly, useful for bumping main or a feature with breaking changes a major increment.
You can think of next-version as a "future" git tag. The value of next-version should be equal to the value of the git tag you are going to add to your next release commit (a merge commit from develop to main, for instance).
As GitVersion is configured to increment either Major, Minor or Patch, for some branches you may want to exercise more control over which version part is incremented. Say GitVersion is configured to increment: Patch, but you know that there are features in develop that warrant a Minor or perhaps even Major increment. You can then use next-version to explicitly control the increment.
I have a code running in Node 9.8
Node 9 will reach End-of-life soon.
If I switch to node 10, how can I check if my code will run in node 10 without having to execute all paths of the code ?
Or if I go down to 8.11, how can I check if my code will run in node 8.11 ?
There is no test cases written on the code.
This is a good example of why solid unit/integration tests are critical to long-term maintainability. That said, there are a few steps you can take to reduce the risk of breaking things:
Take a look at the change logs pertaining to the versions you're moving to/from. The NodeJS team kindly includes a Notable Changes section in each change log, though I wouldn't rely on that alone as being 100% inclusive of the potentially breaking changes you may be up against.
Consider writing unit/integration tests, both as part of your assurance that things won't break from this version change, as well as that things won't break from later version changes (or everyday changes for that matter).
As much as I hate to say it, Googling around for guides on upgrading (or downgrading?) NodeJS versions may help you identify potential danger zones.
Generally, I'd consider it safer and better practice to upgrade the version than downgrade. For one, you're moving forward to the newer and greater experience the NodeJS team wants you work with, and secondly, future versions are probably more likely to be backwards compatible, whereas the old version may be missing features you're using.
I have been recently working on a project that involves the integration of Kafka, Spark and Cassandra. One of the key things I noticed when trying to get the whole thing setup is that there are a lot of version conflicts that needs to be very carefully matched in order to get these technologies to work together.
In addition, it was important to take note of the Scala version used with Spark when writing your own Spark-Jobs.
A slight change in the version of one of the above technologies breaks the complete flow and requires a proper redo of matching them together.
The task was not very straight forward (at least for me and I guess it's the same for all) and I am wondering how do companies which have these technologies working in sync actually manage this?
As I see it, it is an important problem with new releases and bug fixes being rolled out, to keep these tools working together without a break.
Can someone who has experience with regards to this enlighten me as to how companies actually manage/maintain these conflicts?
Or is it an overstatement to say it's an actual problem?
Thanks in advance
Murphy kicked my a$$ about an hour ago.
Context:
I recently joined a new employer and the product was quite outdated in terms of dependencies, Angular 1.2.x, Angular-UI 0.12.0, etc...
This is the first employer I've worked at that does daily builds to prod etc. (previosuly I've only worked in what can be called large corporate, with much slower turn around) Part of my initial task was to upgrade dependencies where I can. Thus earlier this morning we had a watercooler talk with some of the devs about why all of our bower dependencies are hardcoded to specific versions.
The 2 schools of thought are:
Hardcoding versions obviously gives 100% security as versions can't dynamically jump, but has the drawback that if someone doesnt actively update we'll fall behind again.
I'm of the opinion that semantic versioning gives us some form of security (coupled with having multiple staging environments), and that it should be good enough to, say, have Angular set to say ^1.5.9.
Quoted from the Semantic Version Docs:
Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backwards
compatible functionality is introduced to the public API. It MUST be
incremented if any public API functionality is marked as deprecated.
It MAY be incremented if substantial new functionality or improvements
are introduced within the private code. It MAY include patch level
changes. Patch version MUST be reset to 0 when minor version is
incremented.
Problem:
Earlier this morning we deployed to staging, and everything seemed good to go, then we deployed to production an hour or so ago and ... BOOM
The issue was the AngularJs change from 1.5.9, to 1.6.0. I've seen in the migration docs (migrate 1.5 -> 1.6) that this has been noted:
You may also notice that this release comes with a longer-than-usual
list of breaking changes. Don't let this dishearten you though, since
most of them are pretty minor - often not expected to affect real
applications. These breaking changes were necessary in order to:
Question:
Where is my disconnect? ...or is the semantic version docs just a false sense of security I've had all along?
How do people out there in the handle these situations? Do people make use of auto dependency upgrading in any real world solutions (excuse me if this is super obvious to some), as to me, the fact that the build passed staging, and broke in production is actually more concerning.
(The reason I'm asking is because the fear of small incremental updates are now back and stronger than ever, and I'm not sure if I agree with the sentiment of it all...)
Seems pretty simple, if they make breaking changes, they should have bumped it up to 2.0.0. They are not doing semantic versioning. Not all projects using X.Y.Z. style versions are doing semantic versioning.
Try to catch how this went "boom" in an automated way in your testing and staging environments. Can't fear moving forward, it has to be done sometime, and I'd rather move step-by-step more frequently, than to suddendly move up many versions as would be done with an entirely manual process.
I'm working fast and furiously on a new Haskell package for compiler writers. I'm going through many minor version numbers daily, and the Haskell packaging system, Cabal, doesn't seem to offer any tools for updating version numbers or for maintaining a change log. (Logs are going into git but that's not visible to anyone using the package.) I would kill for something equivalent to Debian's uupdate or dch/debchange tools.
Does anyone know of general-purpose tools that could be used to increment version numbers automatically and add an entry to a change log?
I use a very simple scheme to generate my CHANGELOG. I just ask darcs for it and include it in the extra-files section of my package's .cabal file. Though, this seems too simplistic for what you are asking. =)
That said, you can go quite a bit farther and use a custom cabal Setup.(hs|lhs) that builds the CHANGELOG during cabal sdist out of your darcs or git repository's commit info (or out of whatever system you decide to use to track it)
The Setup.lhs used by darcs does something very similar to include information on version numbers and number of applied patches since the last version. Look at the sdistHook and generateVersionModule machinery in Setup.lhs to get an idea of how this can be done.
To non-answer your question, I'm not aware of anything. This sounds like a good match for posting in the Haskell Proposals subreddit, since it seems like a pretty useful idea.