Thank you for that link, it was really fascinating. The Australian government guarantees deposits in the same way, but I never realised this was also true in the US. I had assumed during the mortgage crisis that people lost their deposited money when their banks failed.
Some browsers need a trailing dot - http://ai. - this site was on HN a week or so ago in an article and I guess when they saw the resulting traffic they changed it, used to be the Antilles domain registrar homepage.
At my company we would love to use buf but can't: because of the BSR. We already pay shitloads for our VCS - we don't want to pay for another product that does the same thing. After using go and getting a taste of what life is like without third party package publishers (like npm, pypi, etc) it's hard to want to go back.
I can't agree with having a source file include the tag. It is an eternal source of merge conflicts and pain, unless you take steps to automate it. And in that case, does the file add much value anymore?
My personal experience with go modules and versioning has been really positive. In that ecosystem - you only define your major version in the mod file and rely on the VCS for everything else.
Yeah, I often prefer, when possible, to automate in CI dumping the git describe output to a .gitignored source file and letting tags themselves be the "source of truth".
Related to that "tags as source of truth" is using tags as a deployment trigger. A release manager applying a tag can be a signal or gate for a version to go to later environments. (For instance: CI builds from main branches stop at Dev environments, CI builds triggered from new tags automatically move on to UAT and Staging environments.)
Also, another tip I've found useful for people with more "monorepos": tag name restrictions match branch name restrictions and you can use a "folder structure" of tags. You can name tags things like subcomponent/v1.0.2. Some git UIs even present such tags as a folder structure. Doing that can confuse git describe, of course, so finding an arrangement that works for your project may be a balancing act. I've used lightweight tags for subcomponents so that git describe doesn't "see them" by default and then you can use the git describe --tags that also takes lightweight tags into account if you need a "subcomponent version" for subcomponent tag triggered deployments (and then you just need to remove to remove the folder prefix).
> you can use a "folder structure" of tags. You can name tags things like subcomponent/v1.0.2. […] Doing that can confuse git describe
Using the --match option, `git describe --match='subcomponent/*'` fixes this problem. It filters the tags that are considered to only those matching the pattern, so that a later tag for another subcomponent will not be used.
Yes, having a version number centralised in source code is exactly the thing Git helped us many times to avoid.
Also ties in with the author's recommendation to begin tags with "v". My experience is that excluding it is better. Then a simple "git describe" readily gives the version number in scripts with no sed or reprocessing.
I've seen many conventions with Git. It's interesting to hear some rationale, but a stretch to describe these suggestions as the "proper" way.
The v prefix really helps us only run ci on version tags instead of random tags as well. If you are strict and always use semantic versions for tags, you can just keep doing what you are doing. But if you ever want to create some random tag later and don't want your automation to try to use it as a version number, the v prefix helps.
How is the version information included in the software if you don't include it in the source? Do you have a deploy script that modifies source based on the git tag, or ?
I sometimes dump git describe to a JSON file rather than modifying a source file and let the build bundle it as an embedded resource. You can .gitignore the JSON file to keep it from accidentally getting checked in (and causing merge conflicts).
As also pointed out, many build tools that want or need version numbers often also have command line flags or can take environment variables instead of using source files.
Some languages and build systems also allow you to set constants from compiler flags (Go for example). Other systems make the entire build configuration an executable program (Gradle).
In practice that's a tiny bit more complicated to do it really well, with the version as a dependency in the build process. When developing, you don't want to trigger a full rebuild if the version number changes, but you do have rebuilds to do when it does.
I don't think that it poses an issue with merge conflicts. It is likely not an issue as long as the tagging is only made on the main branch by the release managers.
I know it is working well for Linux kernel hackers. Linus does all the tagging, and I don't recall issues with merge conflicts on the top Makefile with the part that holds the version.
I think you're assuming that all software results in a single "release manager".
In many environments, multiple branches of software are deployed and maintained at the same time.
Even your example with Linux; I don't think that is correct -- Linus doesn't tag the stable branches, and others. There is a centralised agreement of how the version numbers are maintained though.
My example is relevant to tagging in branches that may merge back into the main one. The stable branches in Linux are cherry-pick branches that don't get merged back and therefore creating tags there is harmless.
Tags in git allow just about the same naming options as branches, and "v" prefix is just a convention not a requirement. So rather than applying a tag v1.3.2 you could use a "folder structure" such as library1/v1.3.2 and library2/v3.1.2. Today I learned that you can use `git describe --match="library1/v*"` to get the version relative to just "library1" if you are versioning this way (in a monorepo, for instance).
It seems like what you describe is what golang supports: the folder structure in the tag name must match the folder structure in the repository. That's pretty cool.
Do people use a mono repo approach with different parts of the repo having different version numbers? The way I thought of it, the whole point of mono repo is not that.
In technical interviews I conduct I also include a system design challenge. I present a large scale architecture problem our company has had to solve and ask the candidate to take us through their process of designing a solution.
Excellent candidates are not the same as the ones who arrive at a similar solution to ours. The best candidates are able to ask important questions about the requirements, and when asked can provide rationale for choosing specific components, as well as other potential options they considered.
More often than not this kind of question is assessing your process, not the outcome you produce.
Much like standardized tests are meant to assess objective aptitude but invariably favor those who specifically prepare for the test, which diminishes their objectivity, these types of interviews vastly favor those who specifically prepare for these types of interviews.
The exact same pattern happens with product managers. There are very specific types of interviews and there is an entire industry built around preparing candidates for these types of interviews. At that point, is the interview process still effective? I'm certain there is a pool of fully-capable people out there being left behind in sub-optimal careers for no other reason than they've underestimated or are ignorant of the need to prepare for an interview exercise that is, at best, loosely related to the work they'd actually do.
I suppose the counter-argument would be that good candidates should be able to figure out what they need to do to successfully complete a task, and properly understanding and gaming the interview process showcases that skill.
> Much like standardized tests are meant to assess objective aptitude but invariably favor those who specifically prepare for the test, which diminishes their objectivity, these types of interviews vastly favor those who specifically prepare for these types of interviews.
But those who prepare for system design interviews are most likely better equipped to design systems in real life too, because they had to go through the different problems and types of systems and their requirements.
Now that doesn't mean they can implement it end-to-end, but you could probably tell those who are over-engineering it from those who actually either have experience or solid foundation to make good decisions.
