Re: [Asterisk-java-users] [Asterisk-java-devel] Asterisk-Java 1.0 release et al

[Enguerrand de R. <eng...@el...>]

Hi all

Agree that pushing the current state out as 1.0 and adding fixes in 1.x makes sense.

Two thoughts on higher Asterisk Versions support:


1)      I think it’s ok to have “partial” support for Asterisk 13 in a first step, if the ari stuff looks too ambitious initially. Supporting the new event structure and all that would already be a good step for a 2.x release in my view. ARI support could follow later down the road.

2)      we’d have to agree on a strategy for backwards compatibility. E.g. some user events got some major restructuring in Asterisk 12. Applications that expect the old structure of e.g. Dial-, Hold- and Park Events may no longer work correctly if we just adjust to the new structure. The problems I have encountered so far could be overcome by building additional legacy Events from the new Events and sending them out as well, but that obviously does not lead to cleaner code and may actually produce unexpected side effects.

Cheers
Enguerrand


------------------------------------------------------------------------------------
Dipl.-Ing. Enguerrand de Rochefort
Softwareentwickler
mailto:eng...@el...
Tel:  +49-241-566266-72
Fax: +49-241-566266-29

Von: Peter Katzmann [mailto:pet...@ed...]
Gesendet: Mittwoch, 15. April 2015 09:05
An: ast...@li...
Betreff: Re: [Asterisk-java-users] [Asterisk-java-devel] Asterisk-Java 1.0 release et al

IMHO,
the current git repo is a well known stable base and works for most people out there.
 I would prefer to say that we should clear out the current warnings for missing properties against at least asterisk 11 and release it as 1.0.

This release will the be a great base for integrating all those patches and features.
To get a little bit more speed in development we should look in the next step for some crucial missing features who ar simple to integrate without major side effects.
For example we have a patch for MessageSend incorporated in Asterisk 10, this one will improve the Asterisk-Java but with less side effects.
On the opposite, i have made some changes to overcome the limitation that a user only can have one call waiting. This works for me but could lead to trouble for others because this change is much more deeper hooked in the lib and needs more testing.

peter




-----Ursprüngliche Nachricht-----
Von: Brett Sutton <bs...@no...>
Gesendet: Mit 15 April 2015 03:07
An: ast...@li...; ast...@li...
Betreff: Re: [Asterisk-java-users] [Asterisk-java-devel] Asterisk-Java 1.0 release et al


So I'm a little uncertain of the best path, my thoughts are along the lines of:

There are a number of forks (lots) that have bug fixes which would be useful to get into the 1.0 release.

I also get the impression that a number of the users of these forks have fixes that they deem critical for their environment.

The question then is how many (if any) of these we should wrap up into the 1.0 release.

One possible path is lets just do the 1.0 release as the code stands, so that downloaders have some level of confidence when the get the 1.0 release and lets us get it out the door quickly.

We could then look at a 1.1 release that takes the bug fixes from these many forks.

With either scenario we need to work out how we get the fixes from those forks in to the 1.x release.

We can try contacting some of the developers (I've tried with some but not all have email addresses attached) and request them to send us push requests against the 1.x branch or failing that we could start picking off bug fixes from those forks and generate the pull requests ourselves.

We also need to determine what versions of asterisk we will support for 1.0 vs 2.0

I've included asterisk-users on this thread as while these are development issues I think we need to here what our users need.

So opinions on the best path?

So vote:

Issue 1:
Create release 1.0 using existing code with NO fixes, then 1.1 with fixes.

Create release 1.0 with fixes.

Issue 2:
Request developers to make push requests.

Marshall the forks and do push requests ourselves.

Issue 2 may be a noop in the sense that if fork developers don't respond then we will have to do it ourselves.

Issue 3:
Choose which versions of asterisk must be supported in 1.0.

1.4

1.6

1.8

10

11

12

13

Choose which versions of asterisk must be supported in 2.0


1.4

1.6

1.8

10

11

12

13

14

Brett


On 15/04/15 06:03, Martin Duncan wrote:
Brett,
It all sounds good.  Let me know which has the highest priority and I will start on that.
Regards,
Martin




------------------------------------------------------------------------------

BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT

Develop your own process in accordance with the BPMN 2 standard

Learn Process modeling best practices with Bonita BPM through live exercises

http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_

source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF




_______________________________________________

Asterisk-java-devel mailing list

Ast...@li...<mailto:Ast...@li...>

https://lists.sourceforge.net/lists/listinfo/asterisk-java-devel




--

S. Brett Sutton



Ph: 1300 NOOJEE (1300 666 533)

Noojee Telephony Solutions - On Demand Contact Centres Solutions

www.noojee.com.au<http://www.noojee.com.au>

------------------------------------------------------------------------------


BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT


Develop your own process in accordance with the BPMN 2 standard


Learn Process modeling best practices with Bonita BPM through live exercises


http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_


source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF

_______________________________________________


Asterisk-java-users mailing list


Ast...@li...


https://lists.sourceforge.net/lists/listinfo/asterisk-java-users



Mehr News und Informationen aus der Welt der EDAG Group können Sie in unserem interaktiven EMAG-Magazin<http://www.edag.de/de/services/corporate-services/newsletter.html> nachlesen!
More news and information about the EDAG Group can be found in our interactive EMAG-Magazine<http://www.edag.de/en/services/corporate-services/newsletter.html>!

________________________________


Registergericht/Court of jurisdiction: Amtsgericht Wiesbaden, HRB 28257 USt.-Id: DE 292 939 239
Geschäftsführung / Board of Managing Directors: Jörg Ohlsen (CEO), Harald Poeschke (COO), Jürgen Vogt (CFO)
Aufsichtsratsvorsitzender / Chairman of the Supervisory Board: Thomas Eichelmann
Hauptsitz/Headquarters: EDAG Engineering GmbH, Kreuzberger Ring 40, 65205 Wiesbaden Deutschland/Germany / www.edag.com<http://www.edag.com>

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.


ELARA Leitstellentechnik GmbH Member of Frequentis Group Schloss-Rahe-Str. 19a 52072 Aachen Geschäftsführender Gesellschafter: Dr.-Ing. Frank Herzog Geschäftsführer: Dipl.-Ing. Hans Werner Güntzel Amtsgericht Aachen HRB 17856 St.-Nr.: 201/5956/4218 USt-IdNr.: DE 285 827 521 --------------------------------------------------------------------------------------------- Diese Mail enthaelt vertrauliche und/oder rechtlich geschuetzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e- mail is strictly forbidden.