----- Mail original ----- De: "Randall S. Becker" >> Git is a wonderful tool, which has transformed how software is created, and made code sharing and reuse, a lot easier (both >> between human and software tools). <snip> >> Please please please add release handling and versioning capabilities to Git itself. Without it some enthusiastic >> Git adopters are on a fast trajectory to unmanageable hash soup states, even if they are not realising it yet, because >> the deleterious side effects of giving up on releases only get clear with time. >> Here is what such capabilities could look like (people on this list can probably invent something better, I don't care as >>clong as something exists). <snip> > Nicolas makes some interesting points, and I do suggest looking at the original post, but there are more factors to consider > when dealing with production-grade releases in regulatory environments. And my sincere apologies for what, even in my eyes > looks like a bit of a soap-box rant. No slight intended, Nicolas. Hi Randall. I plead guilty for the rant part, I've spent way too many nightly hours recently untangling Git projects that couldn't be bothered with stating requirements any other way than with a list of commit hashes, when they bothered (in one case a dev didn't even realise had broken some of his other projects when changing code, that's how bad the "a commit hash is a sufficient coordination point" situation is now getting). > Possibly most importantly, there are serious distinctions between what is built via CI, what is released, and what is > installed. Perhaps I should clarify, my post was about "source" release id since git is a "source" code manager. You do need a different id to identify release builds (packaged or not). However, any sane system will derive the build id from the source id, since most software properties (options, functionnalities, security problems) are directly caused by what's in the source itself, and changing them requires going back to the source. > In a specific way, source and release commits are required to be time reversible in production, whereby if an installation > fails, there exist in many environments requirements to be able to fully undo the install action. This is often different > from the environment artifacts which can be time-forward constrained and reversible only in extreme situations. Yes the reversibility is often very theorical, basically requiring losing any change and reverting to a pre-change data dump. Automation is getting to the point where it' simpler to push a new fixed build than reverting to previous state. But that requires solid handover between source-oriented (git), build-oriented, deployment-oriented and audit-oriented tools. >> So nothing terribly complex, just a lot a small helpers to make releasing easier, less tedious, and cheaper for developers, >> that formalize, automate, and make easier existing practices of mature software projects, making them accessible to >> smaller projects. They would make releasing more predictable and reliable for people deploying the code, and easier >> to consume by higher-level cross-project management tools. That would transform the deployment stage of software >> just like Git already transformed early code writing and autotest stages. > Possibly, but primarily for source releases. Sure, you need to start somewhere, and git's job is managing sources, so source releases are part of its theoritical scope. Best regards, -- Nicolas Mailhot
