People who code: we want your input. Take the Survey

Hot answers tagged

73

SemVer concerns versioning releases, not commits. If your version control model happens to require that every commit to master be a release, then yes, every commit will need to be tagged according to the degree of the change. Generally, though, projects develop a mostly stable product on master and tag the releases they deem worthy of support. When they do ...


19

Why would it be a problem over having trunk and branches? A tag is just another branch, but (and perhaps this is the important bit) you do not have to checkout the entire SVN repo. Instead of calling svn co http://repo/ call svn co http://repo/trunk Then, if you want to see a particular branch use svn switch. Everyone I know who uses the trunk/tags/...


13

In practice, because every commit in a git system already has a hash, if all you need is a unique identifier to reproduce a build, or identify a particular state of your branch, you already have that with the commit hash. And obviously your CI system already knows that commit hash. So in this sense, all of those tags are a bit of a waste. Is it bad ...


12

Version numbers are allocated to releases. In general not every commit should be a release. There are several reasons for this. Firstly while you say you "test" every commit there are levels of testing. Running an automated testsuite on one machine is all well and good, but in complex software it probablly wont' catch every issue. Some issues may be ...


12

Can we change XML format (i.e. create a new language which doesn't have the verbosity issue)? Yes, we can. In order to completely migrate to the "better XML" (let's call it BETXML), it would require to: Reimplement all the parsers, Rewrite all applications which currently use XML, Rewrite all protocols based on XML. Or we can keep everything in place, and ...


10

This is done on purpose. They seem to be second-class citizens, or at least "different." They aren't pushed unless you specify that explicitly. Deletions of remote tags doesn't cause deletion in downstream repos. I don't agree with lxrec's answer about git having bad defaults. If you follow the mailing list, you can see that git developpers actually ...


8

I fail to see the big gain with the </> variant. Are you talking about readability for the human eye? In that case I would take ordinary XML any day rather than trying to figure out what the code is trying to tell me when I see something like this in the middle of a file: ... </></></></></></></> &...


7

Subversion's sparse directories is what you are looking for. First time checkout, you should run: svn checkout --depth immediates <URL> This will only checkout the first level, thus only directories if you follow the branches/, tags/, trunk/ convention. Try it; it will not download much. Then go into tags/, and run svn update --set-depth ...


6

A tag in subversion is technically the same as a branch. It is only convention that keeps you from modifying a tag after it was created. Last year I had a situation where we were very happy that we use tags in subversion. We had created a release and tagged that release. In parallel to the acceptance tests on the release, normal development continued on the ...


5

What you're describing is the task of cluster analysis. The goal is to find distinct clusters in data where the elements in the cluster are correlated. The attributes of the data form the "context" that you refer to, and usually cluster analysis is used to classify new data after being trained. For example whether a fruit is considered delicious may ...


5

Kind of putting out the obvious here, but maybe worth to mention it. Usually, git repos are tailored per lib/project because they tend to be independent. You update your project, and don't care about the rest. Other projects depending on it will simply update their lib whenever they see fit. However, your case seems highly dependent on correlated ...


4

The solution you are looking for is a dependency management tool in coordination with git submodules Tools such as: Maven Ant Composer You can use those tools to define dependencies of a project. You can require a submodule to be at least version > 2.x.x or denote a range of versions that are compatible = 2.2.* or less than a particular version < ...


4

Some customer who cannot upgrade to a newer version ask you for support for version x.y.z. A tag with that release will help you identify the code you need to inspect. Ask the new guy to search the release using commit comments. Please, do it!


4

A tag should be created for significant commits — something meaningful. This is a bit open-ended, but most times a tag corresponds to a release, and this is why you tend to see tags like v1.3.5.X or 1.4.0.X. You should not be creating release tags for commits that are not actually releases. Comments on release tags should give you a short description ...


4

I'm in favor of a tagging system over predefined fields when many of them are just going to be N/A. All predefined fields do in those cases is suggest things to think about adding. I don't need a pile of text boxes to suggest a list of things to consider adding. I can use lists, tag clouds, or just a paragraph for that. However, a user defined tagging ...


4

You're building a training set. This is used to teach the AI what you want. The important thing is to be careful that the set doesn't contain false tells like a red and white checkered table cloth every time it's a pasta dish. We all generalize of course but when humans build training data it's amazingly easy to tip your hand without meaning to. Why ...


3

This is a fairly broad question. It's not clear to me if you're looking for algorithms that find the potential tags, or algorithms that can deal witht the fact that the universe is not black or white. For the first aspect, you'd certainly have to look on statistical clustering, neural nets algorithms or other ML techniques. But on the second part, ...


3

In my previous company we had the same problem, we had to "update" old releases e.g. to allow them to run on modern OS oe support a new version of the old hardware. Our solution was your #1, create a branch for each release; we called them "maintenance" branches. Our git looked something like: maintenance/product_v1.0 (tags: v1.1, v1.2, ...


3

Seems to obvious to say, but: a version numbers purpose is to let you easily determine what version of the software anyone is running. If there is any chance of anyone having access to a particular iteration of the code, and not otherwise easily be able to determine a unique identifier, then that iteration should have a unique version number. I see this as ...


3

It's best not to use git flow for a project where you aspire to continuous delivery. As Vincent Driessen, the originator of Git Flow writes: If your team is doing continuous delivery of software, I would suggest to adopt a much simpler workflow (like GitHub flow) instead of trying to shoehorn git-flow into your team. I would suggest instead trying some ...


3

The Method Storing the Data Present the taggable image to the user. Capture mouse clicks on the image and store the coordinates relative to the image where the user clicks. Once they've clicked, you can present the user with a pop-up/modal type form where they can select one of the products from a searchable list and enter any other information you want ...


3

Store hashtags in an array within a document. That's the benefit of having documents: you can simply nest them. And, in this particular case, it's trivial: { "_id": 123, "file": "c43a5f46-kitten.png", "description": "My kitten :3 #kittens #cute" "hashtags": ["kittens", "cute", "cat", "animals"] } (I added some "synonymous" tags, this can ...


2

A tag is precisely made to be able to get the exact snapshot of the sources at the moment you created it. It is 1000000 times more convenient than looking at the submit comments....especially if your release requiered several commits (or more). Furthermore, the case where a important bug is dicovered in acceptance or in production while the development is ...


2

A tag denotes a specific point in development history. It should not change, at all. Ideally, build should be reproducible. This means checking out a tag and building it should - bit-for-bit - produce the exact same artifact, every time. Changing the versions of the build tools involved will alter that. Thats mostly not even desired. But there is an ...


1

I'd suggest making a separate versioned maintenance branch, and create a new versioned tag whenever you re-release an old version with new build environment. That way also, if a bug is caused by the changed build environment, there's clarity on which versions are affected as they'd be on different patch version. If your build system is fairly simple, you can ...


1

If you have no other method of generating training data, then manually constructing them is the only way. After all, anything that isn't automatically done by a computer model is by definition "manual". With more sophisticated algorithms, you can profit from "active learning", i.e. the model has a limited awareness of which examples would be especially ...


1

I think it might be better to keep tags and attributes separate. Attributes are usually name/value pairs and are often (in my experience) typed so that you can't enter the weight of a product as "blue". Tags are just words associated with a product, such as the tags "morning", "caffeine", "I_need_it_bad!" which might go with a coffee maker. Here's an ...


1

1) Why are git tags second-class citizens? Because sadly, git has a lot of bad defaults. As much as I like it, it simply is not a very newbie-friendly or intuitive tool. Pretty much everyone has to set up git configs or aliases or scripts that use a dozen or so of the -- options (like --ff-only) to make git start behaving the way they actually want it to. ...


1

Another reason to use tags instead of revision numbers to track what you released is it's easier to keep links/references to tags than to revisions of trunk (or branches). References to particular paths at some old revision can break if you reorganize your trunk (or branch) folder layout in the future. Tags don't change (by convention), so they don't have ...


1

Yes, you can use the revision number to uniquely identify a snapshot in time. But... where do you record which revnum matches which release? Will you keep a spreadsheet that says "release 4.2.1" is Revnum 18345? Not recommended. However, creating a Tag 'branch' does exactly this without the need for spreadsheets or external tooling - if you remember a ...


Only top voted, non community-wiki answers of a minimum length are eligible