Replies: 1 comment 10 replies
-
|
@HHobeck can you help here? |
Beta Was this translation helpful? Give feedback.
-
Again: The Mainline version strategy implementation in version 6.0.0 (which will be used in the TrunkBased/preview1 workflow) is a new implementation and has nothing to do with the old Mainline mode implementation in 5.12. The new implementation has not the goal to be backward compatible. The previous algorithm was error prone and not maintainable. Thus the initial plan of the maintainers of GitVersion was to delete the algorithm completely without any alternative. Also no one has used it (at least no one we are aware of). Because I personally want to save the workflow I decided to re-implement it from scratch and invest docent of hours in my spare time.
There is no assurance. But I invite you to contribute.
If you like you can analyze the previous code and try to rescue it. But restoring of an old algorithm is not the right way in my opinion. Better understand the new algorithm and implement the feature based on acceptance criterias.
The only features I know of are the following:
But to be honest. I have no idea what features where included in the previous algorithm. At the end I would like to mention that all the time the maintainer and contributer are investing here in this project is unpaid and voluntary. Please keep that in mind before expressing any requirements. |
Beta Was this translation helpful? Give feedback.
-
That is very much appreciated. I think it would have been less confusing had it received a different name, as my query would have opened with 'how do we get something like Mainline back?'. I would be interested, perhaps in a separate thread once other concerns are set aside, to grasp the intent and see how closely it fits.
That's not how open source maintenance works. You as maintainers have to determine the agreed scope of the project - the architectural impact, the feature sets desired to maintain, what is championed as the capabilities of GitVersion. External contributors cannot contribute to a project that is hostile to the concept they want to contribute, so it needs to be understood whether a contribution fits in. This is exactly why forking ends up occurring. If there's no assurance that a contribution won't simply get deleted next week because a maintainer disagrees with it, how can anyone contribute in good faith?
How would you know? I find this assertion curious - does GitVersion do surveys? Data gathering? Is there something we should have participated in? Did you scan github.com for
I don't know the history of this - but consider - if this algorithm was implemented by someone previously involved with GitVersion and now deleted because they've stopped said involvement - this implicitly sends the message that contributions can be removed later if nobody champions them. That would mean you're not asking for contributions; you're asking for additional maintainers, and that is a very important distinction to make in such discussions, since I need to convey this to various leadership.
This is well understood and does not need repeating. Volunteer time on all sorts of open source projects (including my own) is always laudable and appreciated. It does not change that if you want external contributions, as maintainers it has to be clear whether those contributions fit your intended scope. Let me give an example from another recent issue from @arturcic
This indicates the team has discussed contributions and agreed that some will not be accepted. I ask again - are changes like the ones I describe in line with your intended direction for GitVersion? What would keep that workflow alive in future? Presumably someone liked Mainline mode and then it got removed. What prevents future investment being similarly removed? This is a great tool, one that it's clear a lot of people benefit from, and the team should be proud of what has been accomplished. It perhaps might benefit from greater clarity on intent.
I'd invite you to consider the tone of this discussion. I haven't expressed requirements; I have asked questions and am attempting to gauge whether the decisions made in GitVersion 6 are compatible with potential future contributions. In a word, help me (figure out if I can) help you 😄 |
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.
-
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