I've heard quite some buzz about doing day to day development on > FGAddon (and I'm so glad now I have not done this!) - to the degree
that people actually do it, it also ships any temporary breakage to >
the user right away, and it ships inconsistent documentation and >
actual behavior to the user right away.
My system for updating fgaddon repo aircraft always starts locally. I do
the work, test it, and after I am happy with it I push to fgaddon. For
the most part I have had little to no issues doing this. I remain
conscious of where the last stable release of FG is at so as not to push
a new feature that is not available yet.
So in essence, every commit I make to fgaddon is considered release ready.
What I like about this is I can introduce the latest upgrades available
in the current release if not yet implemented without delay as soon as I
implement them. I can fix any bug that pops up and know they are
But I do have to pay close attention.
However with Thorsten's approach, when working on the Shuttle, I don't
have to worry so much about introducing a bug, I know it is only going
to affect the immediate development branch.
From his point of view and the point of development the Shuttle is at,
I think it is a necessity to do it in release stages.
Listening to Thorsten's concerns does give me pause though. If I was
working on a critical system for some company, I would absolutely not do
it directly and would make sure it was well reviewed prior to
introducing it. But in the case of the aircraft I am responsible for,
guess what, I am the only one that reviews it and tests it unless I
introduce it to fgaddon where it gets tested by anyone that uses the sim
and the aircraft from that point forward (or from the point of
"update"). My worst case is a bug report on the forum and I fix it and
everyone is happy.
Bottom line is I see a use case for both approaches.
I wouldn't care if I had a way to update the "stable" version at any
time. If not, even though we're only talking a few months, I would not
be happy about not being able to change or add a feature in the stable
version until the next release.
One more piece to this to give a broader view. On the c172p, during its
most intensive development cycle, when we were submitting 1-10 PR a
week, our system of review before those PR's were allowed to be merged
kept the "main" branch "release ready" pretty much at all times anyway.
I would have no real fear about pointing to the development "main"
branch on that project.
I wouldn't even consider doing this with the Shuttle with the systems
and checks we have in place for it.
So it partially depends on the developers involved and the approaches
and systems they implement.