Replies: 1 comment 12 replies
-
|
@HHobeck can you help here? |
Beta Was this translation helpful? Give feedback.
-
I thought you are asking about an assurance that someone else is implementing it for you. I agree the maintainers need to give the direction or path and help with architectural design decisions. Thus if you asking me the maintainers should:
If the feature or bug has been accepted then it can be solved (by contributor or maintainer) and merged to the production code. In your concrete example I have created a feature ticket and documented the acceptance criteria’s. You can now review it and check if it fits your needs. Because it is not labeled with the triage flag and created from a maintainer you can be sure it is accepted and aligns with the overall design of GitVersion. What do you want more?
Ideally every feature needs to have an acceptance test which ensures the functionality. If you as a contributor want to be sure that your feature remains I would recommend you to write integration tests and document it on the web page. The Mainline mode algorithm lives from the idea in the Mainline version strategy of course. Because of the fact all acceptance tests which were present are still existing and green. This tiny part with pump message
Actually your requirement is additive. If you take a look into the feature #4144 you will see a different regular expression to detect this kind of messages (
Yes that is very kind thank you. I think with the refactoring initiative from 5.0 to 6.0 the code is much more maintainable. Together with the massive number of integration tests GitVersion has -- with its implemented functionalities -- a bright future. :) |
Beta Was this translation helpful? Give feedback.
-
|
@hotchkj, because you mentioned me on my response on the other discussion, I will jump in.
First of all I don't think forking is a bad idea in open source. I actually think it's a good idea because it can serve as a playground for new ideas that can later at some point get integrated into the original repository (or maybe not, but still serves as an ideas sharing mechanism). I can agree that if you as a maintainer want to have good contributions from externals you have to communicate somehow what's the vision medium to long term of the project. And that's what would But, that's not the case in our (and many more) project(s). There are many reasons for that - it's a small project, a small team, and not that many potential contributors willing to invest any time (probably because of the reasons above, but most of them just do not want to spend time at all, and most of them are pretty vocal requesting changes). Now, sometimes we do get some pretty good contributions that fit our vision (that I think has to be vocalized better) and most of them get merged into the main repository. But then there is the catch - these contributions have to be maintained by us, as the original authors are not willing to continue on maintaining their contribution. So long terms it adds up the burden on the maintainers. A good example would be the
We do not do extensive research as big teams/big projects do, mainly because we are a really small team, that spends much of time on maintaining the code. I would really want to do that extensive research to drive the long terms goals of the project, but at least from the moment I joined the team the main driver was how the maintainers use the tool and the most active contributors. Regarding the small team - there are currently 2 main active maintainers - me and @HHobeck (which joined recently, like 1 year or a bit more). We have 2 more maintainers - from the initial maintainers that whenever they have time, help us with code reviews, or whenever we need to consult them. And take in consideration how much time 2+ people can allocate on maintaining the code and other activities (like vocalizing the medium/long terms goals and helping the community that sometimes is really rude). Back to the data gathering/ metrics. We are following the usage of variant distros we publish: GitVersion.Tool and derivates (Chocolatey, winget, homebrew, docker images, GitHub actions, Azure Pipelines) and GitVersion.MsBuild and the effort we put into improving/maintaining each of the deliverables. You know what's interesting - we spend like 65% on the GitVersion.MsBuild (fixes, questions) and 30% on the Core, and the rest for the GitVersion.Tool (and derivates). Now in terms of downloads/usages GitVersion.Tool is the leader - 90% of downloads, with docker/winget/homebrew (which can be included in the GitVersion.Tool as they derivate from it) - 5% and GitVersion.MsBuild - the rest 5%. So I guess it speaks for itself where we should invest our time in. As for the configurations changes that @HHobeck introduced in v6 (major - means breaks stuff).
I think @HHobeck explained, but I can add my cents - the configuration module in place in v6 had to change in a way that is more clear how it works and how to extend/customize. Maybe we need more documentations (like use case scenarios and what should be changed to achieve the wanted use case) , that will be really nice. But the main effort was put on bringing all the "flows" under the same structure and predictable behavior (with many more tests). The way it worked in 5.12 was a bit messy and with different approaches to similar problems.
And as @HHobeck said, it's not abandoned, it's just we need time/people willing to get involved on medium/long term. Now if we talk about the GitVersion 7.0 and later, the goals are:
Sorry I have to go the long way on explaining, but I will later use this post as a reference for other people asking the same questions. Have a good day. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks both for the detailed replies, very useful context! Perfectly understood on the lengthy replies, hopefully others will find them useful as well. I will file the paperwork our end to discuss potential contributions. At this point I can't promise anything, but as we have some vested interest, my hope is that someone on our teams will be able to assist. However, it's got to go through legal etc. first which may take some time... |
Beta Was this translation helpful? Give feedback.
-
|
@hotchkj: May I ask if the paperwork was successful? |
Beta Was this translation helpful? Give feedback.
-
|
@HHobeck still in Legal land at present 😞 it can be a slow process |
Beta Was this translation helpful? Give feedback.
-
I have hundreds of repos configured for 5.12 with a config that is as follows:
Lets' say I have a
masterbranch with a commit tagged withv10.0.0and eight more untagged commits after it, each of which had+semver: nonein the commit message and correspondingly the build versioning skipped these as still producingv10.0.0with no change in tag. GitVersion is being run atHEADofmaster.GitVersion
5.12.0gives me10.0.0with a pre-release tag of8which gets skipped when formingFullSemVer:JSON
{ "Major": 10, "Minor": 0, "Patch": 0, "PreReleaseTag": "8", "PreReleaseTagWithDash": "", "PreReleaseLabel": "", "PreReleaseLabelWithDash": "", "PreReleaseNumber": null, "WeightedPreReleaseNumber": 60000, "BuildMetaData": null, "BuildMetaDataPadded": "", "FullBuildMetaData": "Branch.master.Sha.8947dafe06011c812599eb2b273830d916d367cf", "MajorMinorPatch": "10.0.0", "SemVer": "10.0.0", "LegacySemVer": "10.0.0", "LegacySemVerPadded": "10.0.0", "AssemblySemVer": "10.0.0.0", "AssemblySemFileVer": "10.0.0.0", "FullSemVer": "10.0.0", "InformationalVersion": "10.0.0+Branch.master.Sha.8947dafe06011c812599eb2b273830d916d367cf", "BranchName": "master", "EscapedBranchName": "master", "Sha": "8947dafe06011c812599eb2b273830d916d367cf", "ShortSha": "8947daf", "NuGetVersionV2": "10.0.0", "NuGetVersion": "10.0.0", "NuGetPreReleaseTagV2": "", "NuGetPreReleaseTag": "", "VersionSourceSha": "bf8dcfafbf235762f6e1d9396392dfac9ee690b6", "CommitsSinceVersionSource": 8, "CommitsSinceVersionSourcePadded": "0008", "UncommittedChanges": 327, "CommitDate": "2024-07-18" }which is correct - the package is unchanged.
If I try the suggested migration for 6.0.0, using trunk-based, I get completely different behaviour, so I'm querying - is there actually a 1:1 expected configuration for the above? Is the migration configuration advice incomplete or perhaps yielding assumptions?
GitVersion
6.0.0gives me10.0.8:JSON
{ "AssemblySemFileVer": "10.0.8.0", "AssemblySemVer": "10.0.0.0", "BranchName": "master", "BuildMetaData": null, "CommitDate": "2024-07-18", "CommitsSinceVersionSource": 1, "EscapedBranchName": "master", "FullBuildMetaData": "Branch.master.Sha.8947dafe06011c812599eb2b273830d916d367cf", "FullSemVer": "10.0.8", "InformationalVersion": "10.0.8+Branch.master.Sha.8947dafe06011c812599eb2b273830d916d367cf", "Major": 10, "MajorMinorPatch": "10.0.8", "Minor": 0, "Patch": 8, "PreReleaseLabel": "", "PreReleaseLabelWithDash": "", "PreReleaseNumber": null, "PreReleaseTag": "", "PreReleaseTagWithDash": "", "SemVer": "10.0.8", "Sha": "8947dafe06011c812599eb2b273830d916d367cf", "ShortSha": "8947daf", "UncommittedChanges": 328, "VersionSourceSha": "f327e3cc4c5b92b77dd186198d2bb4262c1473fd", "WeightedPreReleaseNumber": 60000 }which is incorrect; the package hasn't changed so the version should not have done so either.
What is the migration path to yield original behaviour? My expectation is that the versioning should be driven by the last tag, particularly since the interposed commits are all marked with the
nonesemver message.I cannot find any up-to-date documentation on either
Mainlineas a strategy (or indeed what any of the strategies actually do), and the documentedTrunkBasedstrategy does not appear to exist.Assistance/advice would be appreciated. I am suspecting I need to replace
strategiesbut since I clearly don't grasp what these are actually doing, I would like some help in understanding the functionality.What I am attempting to achieve:
masterwas last tagged with1.2.0, then absent any other commit messaging, the next version should be1.2.1i.e. defaulting to a patch; if the next commit contains+semver: featurethen it should yield1.3.0; our build system will then apply a tag accordingly+semver: noneto indicate that the version should not change, and correspondingly no tag should be addedsupportbranch was last tagged with1.3.2then the next version should be1.3.3Beta Was this translation helpful? Give feedback.
All reactions