Reputation
1,425
Top tag
Next privilege 2,000 Rep.
Edit questions and answers
Badges
3 11 23
Impact
~60k people reached

  • 0 posts edited
  • 1 helpful flag
  • 26 votes cast
Jan
19
awarded  Great Question
Nov
4
awarded  Popular Question
Oct
19
awarded  Notable Question
Oct
1
comment Does Semantic Versioning allow 4 components in version numbers?
Concerning your edit at the top: Let me play devil's advocate here. PCI audits cost the company money, and not every feature implemented is of concern to them. So why incur cost and other overhead on principles alone? How is this so concerning? I realize the method of determining audits is probably flawed, but separation of concerns seems reasonable. Things not remotely related to card processing are irrelevant to PCI.
Oct
1
comment Does Semantic Versioning allow 4 components in version numbers?
@enderland Yes basically. MAJOR(PCI).MINOR(PCI).FEATURE.HOTFIX+BUILD. We're basically only allowed to change the 3rd and 4th component without getting PCI (and subsequently the PCI overlords at the company) involved. To me it feels like this is a bit contrived, I am not sure they are justified in the way they manage the version number, but I do not know enough about PCI and audit process to say otherwise.
Oct
1
comment Does Semantic Versioning allow 4 components in version numbers?
+1 for the public API note. We do not have a public API but we do have the ability to break backward compatibility in other aspects, such as data. It's possible we ship a build that gets installed over old releases but data does not change, and we are no longer able to read in that data (usually we support the old formats though)
Oct
1
comment Does Semantic Versioning allow 4 components in version numbers?
I should have clarified on my PCI comment. The issue is that audits and their cost influence when the major and minor components change, not necessarily a true new feature. For example, if a feature related to payments is introduced, we bump the minor number for PCI. But if we add a brand new feature related to something in the gui, it doesn't. Only the patch changes. So in this case we don't really get a say in the matter as developers since someone else makes those decisions.
Oct
1
awarded  Disciplined
Oct
1
revised Does Semantic Versioning allow 4 components in version numbers?
edited title
Oct
1
answered gitflow model with UAT releases is too chaotic, how to simplify?
Oct
1
comment Is it good practice to store software version numbers in VCS?
I hate to leave yet another comment here, but can anyone address my questions above?
Oct
1
asked Does Semantic Versioning allow 4 components in version numbers?
Sep
14
comment gitflow model with UAT releases is too chaotic, how to simplify?
Our QA people are not programmers and probably never will be. That won't be a viable solution. Also submodules are required in Git to avoid monolithic repositories. Sparse checkouts are not available like they are in SVN. Kind of beside the point, though.
Sep
3
comment gitflow model with UAT releases is too chaotic, how to simplify?
We tried having QA merge, but with submodules it became too much of a burden for them. Plus the developer may want to rebase and such prior to merging, and QA wouldn't have the domain expertise to resolve conflicts. Also we do employ feature toggles but not in the truest sense: There is still inherent risk of regressions due to legacy code and common libraries when code is changed for said feature.
Sep
2
comment gitflow model with UAT releases is too chaotic, how to simplify?
Sure, but you didn't address the release branch concern
Sep
2
comment Is it good practice to store software version numbers in VCS?
I'm surprised this idea gets so many upvotes (probably because it sounds good) while the issues mentioned in my previous comments are not addressed.
Sep
2
revised gitflow model with UAT releases is too chaotic, how to simplify?
added 86 characters in body
Sep
2
asked gitflow model with UAT releases is too chaotic, how to simplify?
Aug
21
awarded  Nice Question
Aug
20
comment How do you achieve a numeric versioning scheme with Git?
@JonPurdy Tags are not traditionally used to define a "starting" point, however. In any case, the start will always be the commit tagged as the last release. So I don't see a reason to tag a commit 2 times for this purpose.