On Wed, Jan 15, 2020 at 10:20 AM Justin Taylor <JUSTIN@xxxxxxxxxxxxx> wrote:
I assume by "CMS" you mean source control and not Content Management System.
In the midrange space, people usually talk about "change management",
which entails not just source control but the entire deployment chain
as well. So I would guess CMS stands for "change management system"
here. (Or the S could be "software" or "solution".)
2. Traditional IBMi source control often handles things like builds and deployment, while Git is just for source control.
Honestly, there isn't such a thing as "traditional IBMi source
control"[1], except as PART OF change management.
Also, from the other side of things (outside the midrange space), the
preferred term isn't "source control" either! Though you can say
"source control" and be understood perfectly well, Git and its ilk
bill themselves as source *version* control, which gives a better
picture of what is really being controlled.
John Y.
[1]To be fair, David used the term SCM, which I understand as "source
control management", when he was talking about comprehensive change
management. And he's not the only one who does this. I definitely
disagree with using SCM this way, but I can sort of understand that it
evolved this way for midrange because (a) "source control" sounds more
compatible with the outside world and (b) the pervading sensibility of
the midrange platform is that things should be integrated and turnkey,
and thus if you want source control, you'll naturally want all other
aspects of change management to come along with it. So "source
control" and "change management" are often interpreted as more-or-less
interchangeable for midrange. Whereas the pervading sensibility in the
Unix world is that things should focus on one task, do it well, and be
mix-and-matchable with other single-purpose tools. Git is equally
useful for managing source code in any programming language, but build
systems are often tailored to the needs of a particular language or
family of languages, for example. Or some link in the deployment chain
can be improved upon, and you can just swap that piece out for
something better, without throwing away the whole system. You can't
say "I like the way Aldon handles source code but I prefer the way
Turnover handles objects, so I'll just use Aldon for the one and
Turnover for the other".
midrange.com
