would have pros and cons...
but in my opinion more cons..:
asterisk version-numbers may be x , x.y, and even x.y.z how far will
you follow this scheme?
asterisk-patches may make it even worse.
what, if changes are not affecting asterisk-java at all? release a
pseudo-new version anyways?
how many branches will we have in a few years...
i think it would be better to have an own versioning, a changelog where
supported versions
are noted, maybe an api-call to get supported asterisk-versions as well
as detecting the
asterisk-version on startup and maybe logging out some warnings if
versions do not match..
yves
Am 04.06.2015 um 14:49 schrieb Brett Sutton:
> One of our developers has suggested a slightly novel versioning scheme
> that I thought worth putting to the group.
>
> The idea is to use the asterisk version no. as our version no.
>
> So our current v 1.0 would become v 1.8 as it supports up to asterisk 1.8
>
> The current master would become version 13 as its supports up to version 13.
>
> Its not quite a standard versioning convention but I do wonder if it
> would make users life easier by making it more obvious which version of
> our libraries to download?
>
> Thoughts?
>
---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus
|
