It would be nice to strip out some/most of the per version conditionals
in tests. The need to always cherry-pick changes is the only pitfall I
see with your proposal. If a test never had per version differences
then the cherry-pick is trivial amount of extra work, but for tests with
differences per branch it would mean dealing with conflicts. In the
testsuite I think I'd rather deal with per branch conditionals over
merge with conflicts.
I just want to propose an alternative way of (mostly) accomplishing the
goal. We could create a tag '12' from current master. This would
represent the last revision of the testsuite known to work with Asterisk
12 and below. We would then be free to remove compatibility with EOL
Asterisk branches from testsuite master. We would tag testsuite '14'
soon after September 26th, 2018 (EOL for Asterisk 14). This would avoid
multiplying the number of gerrit reviews for testsuite changes, but it
would require continuing to maintain version declarations for supported
versions of Asterisk. I think this would be a good trade-off so we
aren't stuck with all the 1.8/11 baggage.
On 12/15/2017 11:59 AM, Kevin Harwell wrote:
Greetings,
We're thinking about adding a branching system to the Asterisk
Testsuite. Each branch would be named the same as, and correspond to,
an Asterisk branch. So for instance the following branches would
probably be created:
13, 14, 15
For each release of Asterisk we will also create a tag in the
Testsuite that corresponds to that release's tag. That way someone
could checkout both tags for easy testing
Other advantages? Most all, if not all, the current versioning stuff
found in the Testsuite could go away, or be safely ignored moving
forward. The versioning has become a bit cumbersome especially when
you have to make a backward incompatible change to a test. Moving the
version control out of the Testsuite and into a version control system
should alleviate the need for this moving forward.
Please let us know your thoughts and considerations on moving forward
with this model. Especially any potential pitfalls or problems you
might see with it.
Thanks!
--
Kevin Harwell
Digium, Inc. | Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at:http://digium.com &http://asterisk.org
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
