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 ...
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/...
Your question asked if it's "good practice or legal".
Firstly: it's sort-of legal - at least, it's tolerated. Browsers have always been programmed to cope with tags they don't understand, even if that means they just ignore them. This HTML code:
Some <b>bold</b> and some <slanted>italic</slanted>.
Will appear like this is every ...
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 ...
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 ...
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 ...
If you need to keep the semantics of <important/> for specific reasons, you can use XSL to transform your custom tags into valid HTML. You can read more on this topic here:
There are quite a few answers here explaining why you should never create your own custom tags. Arguably, they are all incorrect.
WHATWG's analysis of custom tags concludes that they are acceptable, standards compliant (since the handling of unrecognized tags is well defined) and more accessible than, for instance, styling a generic div.
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:
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 ...
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 ...
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 ...
Heh, I never thought that by using the @author tag I was claiming ownership of the code, in my mind it was more of a "if this breaks, blame me" comment. I've long given up on writing such comments though, version control is my preferred way of finding who to blame when stuff break.
If you must show code ownership in the legal sense, then have your @author ...
The author tag may serve two purposes:
Claim code ownership
Provide a point-of-contact for future code maintenance needs
Purpose 1 may be a legitimate use for some projects, but its use must be governed and enforced by the project team. For commercial closed-source project, it is likely that this usage could be forbidden.
Purpose 2 may serve a legitimate, ...
Your question makes little sense as is. RDFS is a very basic schema language to express RDF constraints. OWL is more advanced schema to express a complicated ontology. They have absolutely nothing in common with XML except that they can be expressed in XML.
Go with your first approach, it is pretty much the standard way of modeling this type of relationship. (updated to record user who added the tag)
You could also do this by adding a UserID column to the ItemTags table and allowing duplicate rows for ...
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 ...
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 ...
It depends on how cleanly all these elements are separated.
In order to put clarification on how exactly i see things - i am trying to put general
As you highlighted you can deal with this in two ways -
A. Single Product Approach
The entire space is one projects and while they are fairly independent - the repo doesn't recognize it.
In this case few ...
On the practical side, it is unnecessary to use new tags for highlighting. You can use em or i tags if you prefer italics as default (non-CSS) rendering and strong or b if you prefer bolding as default. If, for some reason, you prefer default rendering as normal text, i.e. no highlighting, use span. In each case, you can use a class attribute to distinguish ...
RDF/OWL vs XML is false alternative. In fact one of popular serialization is using XML.
Also RDF/OWL vs microformats is false alternative. In fact there are standards that allow using RDF as an microformat, eRDF and W3C's official RDFa with standardized way of embedding it in HTML5.
So truly the question is what the advantage of using standard, W3C ...
The solution you are looking for is a dependency management tool in coordination with git submodules
Tools such as:
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 < ...
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!
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.
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 ...
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 ...
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:
"description": "My kitten :3 #kittens #cute"
"hashtags": ["kittens", "cute", "cat", "animals"]
(I added some "synonymous" tags, this can ...
Couldn't diagree more with ZJR's answer. It is utterly uninformed.
How do you parse Microdata? What does it parse too? RDFa parses to RDF, a common data model that is the thing the Semantic Web has been crying out for. Microdata basically came about because Hickie couldn't be bothered to read the RDF and RDFa specs. It might be easier for a developer, but ...