asterisk-java-devel

[Asterisk-java-devel] Asterisk-Java 1.0 release et al

[Brett S. <bs...@no...>]

Gentlefolk,
I've just been added by Stefan as a contributor to Asterisk-Java over at 
GitHub (the official repository for asterisk-java).

Noojee is a long time user of Asterisks Java and we are aiming to get 
the project re-invigorated as Stefan is busy off working on other 
projects these days.

The first objective is to get an official 1.0 release out the door which 
essentially is just a snap shot of the existing code with a few bug 
fixes and a few minor enhancements that Noojee has been using for some time.

Once we have 1.0 out the door the aim is to work on 2.0 in which we 
would be looking to support asterisk 11 and 13 as well as merging many 
of the enhancements which have been worked on in many of the forks of 
asterisk-java.

So we are looking for contributors to help:

marshal commits via submitting pull requests for well tested bug fixes 
to asterisk-java 1.0
creation/marshalling of unit tests for 1.0
creation of docker instances for each of the support version of asterisk 1.0
agreement on what versions of asterisk 1.0 will support (1.4, 1.8,...).
general testing of the release candidates we will be pushing out.
other things that the community feel are important.
setup a better communications framework
moving issue tracking to github

Can you help?

Do you have any suggestions as to what we need to be doing?



Brett

[Asterisk-java-devel] Asterisk-Java 1.0 release et al

[Martin D. <md...@du...>]

Brett,

It all sounds good.  Let me know which has the highest priority and I will
start on that.

Regards,

Martin

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

[Brett S. <bs...@no...>]

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...
> 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

[Asterisk-java-devel] 1.1 release

[Brett S. <bs...@no...>]

So given we have a decision on the 1.0 release lets nail down the 
details of 1.1.

Give the low response I'm inclined to do the following.

Create a 1.1 branch (need some help here should this be from the 1.0 
branch or from master)

The 1.1 branch will support the following

1.4

1.6

1.8

10

Subject to the assumption that we don't have to add any new major 
features to support these versions.
1.1. should be considered a bug fix release with perhaps a few wholes 
filled with minor features.

An example of an acceptable feature might be support for a new action or 
event.
An example of an un-acceptable feature would be anything that requires 
significant restructuring of the code.

1.1. should be a nice gentle release which aims to break nothing.


Do we have someone(s) prepared to start the process of marshalling 
appropriate bug fixes and features into 1.1?

Objections?
Suggestions?

Brett

Re: [Asterisk-java-devel] 1.1 release

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

Can we talk about the branching strategy a bit more, I am not sure I am clear about the direction here.
I just forked the repo on Github and would start incorporating changes I'd like to see in 1.1.

I'd expect to branch each release branch off of develop and would hence be committing my changes to develop. However, Brett's mail below says we'll branch off 1.1. from 1.0, so now I am a bit confused.

Can someone enlighten me as to which branch I should be working on to prepare something to be shared back via a pull request.

Thanks
Enguerrand


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

-----Ursprüngliche Nachricht-----
Von: Brett Sutton [mailto:bs...@no...]
Gesendet: Freitag, 17. April 2015 02:48
An: ast...@li...
Betreff: [Asterisk-java-devel] 1.1 release

So given we have a decision on the 1.0 release lets nail down the details of 1.1.

Give the low response I'm inclined to do the following.

Create a 1.1 branch (need some help here should this be from the 1.0 branch or from master)

The 1.1 branch will support the following

1.4

1.6

1.8

10

Subject to the assumption that we don't have to add any new major features to support these versions.
1.1. should be considered a bug fix release with perhaps a few wholes filled with minor features.

An example of an acceptable feature might be support for a new action or event.
An example of an un-acceptable feature would be anything that requires significant restructuring of the code.

1.1. should be a nice gentle release which aims to break nothing.


Do we have someone(s) prepared to start the process of marshalling appropriate bug fixes and features into 1.1?

Objections?
Suggestions?

Brett



------------------------------------------------------------------------------
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...
https://lists.sourceforge.net/lists/listinfo/asterisk-java-devel
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.

Re: [Asterisk-java-devel] 1.1 release

[Brett S. <bs...@no...>]

Enguerrand,
so frankly I'm not certain of the best way to move forward.

Here are the issues as I see them (from a non git expert)

Reading up on branching strategies seems to imply that you normally 
branch from develop.

My concern with branching from develop, for 1.1, was that I'm not 
certain just how much code has been pushed into develop and of what 
quality it is. It may also have a fair amount of asterisk 11/13 code 
which 1.1 is not really about.

Going back to the wiki release notes, 1.1 is intended to only collect up 
small enhancments against 1.4, 1.6, and 1.8.

Having said that, the 11/13 code in develop is probably not harmful.

I note there there are also a number of outstanding pull requests that 
we need to resolve.
Would you be happy to have a look at merging those back into develop?

There are also a small no. of changes in 1.0 which won't be in develop.
Are you able to merge these into 1.1?

So the end result is that I'm prepared to be guided on this one.

If you think we can branch from develop and still get a stable release 
without massive amounts of effort then go ahead and branch from develop.

I've previously suggested that we should follow this model.

http://nvie.com/posts/a-successful-git-branching-model/

Brett




On 29/04/15 00:48, Enguerrand de Rochefort wrote:
> Can we talk about the branching strategy a bit more, I am not sure I am clear about the direction here.
> I just forked the repo on Github and would start incorporating changes I'd like to see in 1.1.
>
> I'd expect to branch each release branch off of develop and would hence be committing my changes to develop. However, Brett's mail below says we'll branch off 1.1. from 1.0, so now I am a bit confused.
>
> Can someone enlighten me as to which branch I should be working on to prepare something to be shared back via a pull request.
>
> Thanks
> Enguerrand
>
>
> ------------------------------------------------------------------------------------
> Dipl.-Ing. Enguerrand de Rochefort
> Softwareentwickler
> mailto:eng...@el...
> Tel:  +49-241-566266-72
> Fax: +49-241-566266-29
>
> -----Ursprüngliche Nachricht-----
> Von: Brett Sutton [mailto:bs...@no...]
> Gesendet: Freitag, 17. April 2015 02:48
> An: ast...@li...
> Betreff: [Asterisk-java-devel] 1.1 release
>
> So given we have a decision on the 1.0 release lets nail down the details of 1.1.
>
> Give the low response I'm inclined to do the following.
>
> Create a 1.1 branch (need some help here should this be from the 1.0 branch or from master)
>
> The 1.1 branch will support the following
>
> 1.4
>
> 1.6
>
> 1.8
>
> 10
>
> Subject to the assumption that we don't have to add any new major features to support these versions.
> 1.1. should be considered a bug fix release with perhaps a few wholes filled with minor features.
>
> An example of an acceptable feature might be support for a new action or event.
> An example of an un-acceptable feature would be anything that requires significant restructuring of the code.
>
> 1.1. should be a nice gentle release which aims to break nothing.
>
>
> Do we have someone(s) prepared to start the process of marshalling appropriate bug fixes and features into 1.1?
>
> Objections?
> Suggestions?
>
> Brett
>
>
>
> ------------------------------------------------------------------------------
> 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...
> https://lists.sourceforge.net/lists/listinfo/asterisk-java-devel
> 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.
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Asterisk-java-devel mailing list
> 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

[Asterisk-java-devel] 2.0 release

[Brett S. <bs...@no...>]

So lets talk about the 2.0 release.

The objective of 2.0 will be to support Asterisk Java 11, 12 and 13 in 
addition to the already supported versions.

At this point I don't see 2.0 supporting ARI, I'm thinking that should 
be a 3.0 target.

I do however want to open up the discussion about improving the 2.0 
interface.

One concern I have with what I'm about to propose is that it has the 
potential to break binary compatibility.

But lets talk anyway.

One of the frustrations I have with asterisk java is that Channels and 
Endpoints are all treated as string.
There are a number of places in the code base that claim something is a 
channel when if fact it isn't.

To solve this problem in our code base we have a event/action 
translation layer which converts Channels and End point strings to 
actual classes of the same name.

Once the conversion is down we have found that it significantly reduces 
the amount of code to handle channels and end points as well as reducing 
the bugs around handling nulls and empty strings.

The second and related issues is that the method of using strings to 
store channels is that it causes problems when rename events occur. Its 
my understanding that in 13 and the new sip libraries that rename events 
go away. That however doesn't help anyone using an earlier version of 
asterisk java and it means that you have to have two different code 
bases to handle the different versions of asterisk.

In our code base along with the above classes for Channels and Endpoints 
we also transparently handle rename events. The Channel object is 
actually a proxy for the actually channel so we can rename the Channel 
under the hood with the code needing to be aware of the change.

So Noojee is willing to donate the code we have to does the above. The 
question is whether it will cause a major breakage of code (uncertain 
although a decent toString method on the classes may make this 
transparent) and whether we should be considering what amounts to a 
fairly major change to the code base.

Here are the interfaces we use:


package au.com.noojeeit.pbx;

import au.com.noojeeit.pbx.asterisk.InvalidChannelName;

/**
  * Provides an abstraction for an channel object which is independent 
of the
  * underlying PBX.
  *
  * @author bsutton
  *
  */
public interface iChannel
{
     /**
      * Compares if two channels are the same logical channel on the pbx.
      *
      * This comparison uses the full unique name of the channel not 
just the
      * abbreviated peer name. e.g. SIP/100-00000100
      *
      * @param rhs
      * @return
      */
     boolean isSame(iChannel rhs);

     boolean isSame(String channelName, String uniqueID);

     /*
      * This comparision uses just the peer name. e.g. SIP/100
      */
     boolean sameEndPoint(iChannel rhs);

     /*
      * This comparision uses just the peer name. e.g. SIP/100
      */
     boolean sameEndPoint(iEndPoint endPoint);

     /**
      * Compares if this channel is the same as the named channel.
      *
      * @param channelName
      * @return
      */
     boolean sameExtenededChannelName(String channelName);

     /**
      * This method does not actually change the state of the channel, 
rather it
      * is intended to be used to record the fact that the state has 
changed.
      *
      * @see public iPBX.iParkCallActivity park(iChannel channel, Direction
      *      direction, boolean parkState) for a method which actually 
parks the
      *      channel.
      */
     void setParked(boolean parked);

     /**
      * This method does not actually change the state of the channel, 
rather it
      * is intended to be used to record the fact that the state has 
changed.
      *
      * @see public iPBX.iMuteCallActivity mute(iChannel channel, Direction
      *      direction, boolean muteState) for a method which actually 
mutes the
      *      channel.
      */
     void setMute(boolean muteState);

     /**
      * Each channel is assigned a unique PBX independent id to help 
track the
      * channels when logging.
      *
      * @return
      */
     long getChannelId();

     /**
      * Returns true if the channel is alive. A channel is considered to 
be alive
      * from the moment it is created until we get a notification that 
it has
      * been hungup.
      *
      * @return
      */
     boolean isLive();

     /**
      * Adds a listener to the channel. The channel will send a hungup
      * notification to the listener when it hungup. A channel must be 
able to
      * support multiple listeners.
      *
      * @param call
      */
     void addListener(iChannelHangupListener listener);

     void removeListener(iChannelHangupListener listener);

     /**
      * Returns true if the given endpont is currently connected to this 
channel.
      *
      * @param extension
      * @return
      */
     boolean isConnectedTo(iEndPoint endPoint);

     /**
      * returns a fully qualifed channel name which includes the tech. e.g.
      * SIP/100-00000342
      *
      * @return
      */
     String getChannelName();

     iEndPoint getEndPoint();

     /**
      * Checks if this channel is currently mute. A channel is mute if 
the party
      * connected to this channel cannot hear any audio.
      *
      * @return
      */
     boolean isMute();

     /**
      * In Asterisk speak, this method returns true if it is a LOCAL/ 
channel Not
      * quite certain how this will map to other pbx's
      *
      * @return
      */
     boolean isLocal();


     /**
      *
      * @return true if the channel is currently parked.
      */
     boolean isParked();

     /**
      * Returns true if the channel has been marked as in a zombie state.
      *
      * @return
      */
     boolean isZombie();


     /**
      *
      * @return true if the channel was originated from the console
      *         (Console/DSP).
      */
     boolean isConsole();

     /**
      * Returns the current callerid for this channel.
      *
      * Note: on some systems this involves a round trip to the pbx.
      *
      * @return
      */
     iCallerID getCallerID();

     /**
      * Called to rename a channel
      *
      * @param newname
      *            the new name of the channel
      * @throws InvalidChannelName
      */
     void rename(String newName) throws InvalidChannelName;

     /**
      * Returns a PBX specific version of the Channel name.
      *
      * @return
      */
     String getExtendedChannelName();

     void notifyHangupListeners();

     boolean canDetectHangup();

     boolean isQuiescent();

     boolean hasCallerID();

}


package au.com.noojeeit.pbx;

import au.com.noojeeit.pbx.asterisk.core.Tech;

/**
  * Provides an abstract interface for entities which can be dialed.
  *
  * This encompasses entities such as: Phone extensions SIPPeers Asterisk
  * extensions External phone numbers
  *
  * @author bsutton
  *
  */
public interface iEndPoint extends Comparable<iEndPoint>
{
     public boolean isSame(iEndPoint rhs);

     public boolean isLocal();

     public boolean isSIP();

     /**
      * Returns the fully qualified name of the EndPoint including the 
tech. e.g.
      * SIP/100
      *
      * @return
      */
     public String getFullyQualifiedName();

     /**
      * Returns the simple name of the EndPoint sans the tech. e.g. 
SIP/100 would
      * be returned as 100.
      *
      * @return
      */
     public String getSimpleName();


     /**
      * Returns the simple name of a SIP EndPoint sans the tech. e.g. 
SIP/100 would
      * be returned as 100.
      * If the endpoint is not actually a SIP end point then this method
      * returns the full end point name.
      *
      *
      * @return
      */
     public String getSIPSimpleName();

     /**
      * Returns true if the tech is not know for this end point.
      *
      * @return
      */
     public boolean isUnknown();

     /**
      * Returns the Tech that is used to reach this endpoint.
      *
      * @return
      */
     public Tech getTech();

     public boolean isEmpty();

     /**
      * Sets the tech on the end point to the specified tech.
      *
      * @param sip
      */
     // public void setTech(Tech tech);

}

Re: [Asterisk-java-devel] 2.0 release

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

Hi Brett

I can say that
"it means that you have to have two different code bases to handle the different versions of asterisk."
would not work for us. For a smooth  roll-out of Asterisk 13 we need to support Asterisk 13 and all currently supported versions in parallel.

That said, if I am the only one who sees it that way it should not affect your decision on how to proceed, because I have already brought the current codebase to a level that works with Asterisk 13 and Asterisk 1.4 in parallel, so for us the problem is addressed, albeit in a way that only covers the features our application actually makes use of. Anyways, I am thinking that others might be in the same situation.

This goes back to my previous mail regarding backward compatibility, which first went to asterisk-users by mistake and then was bounced by asterisk-devel because it exceeded 40 kb (which is why I removed your mail from this reply, so hopefully this one goes through). The key sentence was

"I think 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."

Regards
Enguerrand

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


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.

Re: [Asterisk-java-devel] 2.0 release

[Zoumana T. <zou...@gm...>]

Hello everyone,

Same as Enguerrand, IMHO we shoud consider keeping the backwards
compatibility not forcing projects to have different code bases and builds
processes...

Regards,
Zoumana
Le 17 avr. 2015 10:07, "Enguerrand de Rochefort" <
eng...@el...> a écrit :

> Hi Brett
>
> I can say that
> "it means that you have to have two different code bases to handle the
> different versions of asterisk."
> would not work for us. For a smooth  roll-out of Asterisk 13 we need to
> support Asterisk 13 and all currently supported versions in parallel.
>
> That said, if I am the only one who sees it that way it should not affect
> your decision on how to proceed, because I have already brought the current
> codebase to a level that works with Asterisk 13 and Asterisk 1.4 in
> parallel, so for us the problem is addressed, albeit in a way that only
> covers the features our application actually makes use of. Anyways, I am
> thinking that others might be in the same situation.
>
> This goes back to my previous mail regarding backward compatibility, which
> first went to asterisk-users by mistake and then was bounced by
> asterisk-devel because it exceeded 40 kb (which is why I removed your mail
> from this reply, so hopefully this one goes through). The key sentence was
>
> "I think 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."
>
> Regards
> Enguerrand
>
>
> ------------------------------------------------------------------------------------
> Dipl.-Ing. Enguerrand de Rochefort
> Softwareentwickler
> mailto:eng...@el...
> Tel:  +49-241-566266-72
> Fax: +49-241-566266-29
>
>
> 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.
>
>
> ------------------------------------------------------------------------------
> 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...
> https://lists.sourceforge.net/lists/listinfo/asterisk-java-devel
>

Re: [Asterisk-java-devel] 2.0 release

[Brett S. <bs...@no...>]

So clearly I was very clear in my original post, so let me take a minute 
to clear things up so we have a clear view of where we are going.  Is 
that clear :)

So the intent for 2.0 is that it will support version of Asterisk from 
1.4 to 13.

There will be no need to run different versions of Asterisk java to 
support different version of asterisk.

 From the 3.0 version its probably worth think about culling some of the 
older versions, but this will depend on how hard it is to support the 
older versions.

In the end the version that we support really comes down to what test 
environments we can managed to set up.

As Enguerrand has suggested and as Stefan has down previously we can 
normally support both versions by mapping older legacy events actions to 
the new action/events.  We will obviously have to look into this on a 
case by case basis but I'm moderately confident that this can be 
managed. The only issue will be where an older version of asterisk 
doesn't support some of the attributes provided by the latest version.

So hopefully that makes things a little clearer.

Now my statements about breaking compatibility where not with respect to 
the version of asterisk. What I was talking about was the possibility of 
breaking the asterisk-java api compatibility in an effort to make the 
events/actions easier to use. The main idea being to replace channel and 
endpoint string in events and actions with actual classes.

As an example the current LogChannelEvent has the following fields:

    private String channel;
     private Boolean enabled;
     private Integer reason;
     private String reasonTxt;


These fields would be modified to be:

    private iChannel channel;
     private Boolean enabled;
     private Integer reason;
     private String reasonTxt;

Where iChannel is an interface to a Channel implementation that provides 
a set of useful channel related operations.

Our experience with doing the substitution is that interacting with 
asterisk becomes much easier, the code is easier to read and we 
eliminated a number of bugs at compile time.

Have I made this clearer?

What do people think about the idea of using classes for channels and 
endpoints rather than strings?

Brett



On 17/04/15 20:03, Zoumana TRAORE wrote:
>
> Hello everyone,
>
> Same as Enguerrand, IMHO we shoud consider keeping the backwards 
> compatibility not forcing projects to have different code bases and 
> builds processes...
>
> Regards,
> Zoumana
>
> Le 17 avr. 2015 10:07, "Enguerrand de Rochefort" 
> <eng...@el... 
> <mailto:eng...@el...>> a écrit :
>
>     Hi Brett
>
>     I can say that
>     "it means that you have to have two different code bases to handle
>     the different versions of asterisk."
>     would not work for us. For a smooth  roll-out of Asterisk 13 we
>     need to support Asterisk 13 and all currently supported versions
>     in parallel.
>
>     That said, if I am the only one who sees it that way it should not
>     affect your decision on how to proceed, because I have already
>     brought the current codebase to a level that works with Asterisk
>     13 and Asterisk 1.4 in parallel, so for us the problem is
>     addressed, albeit in a way that only covers the features our
>     application actually makes use of. Anyways, I am thinking that
>     others might be in the same situation.
>
>     This goes back to my previous mail regarding backward
>     compatibility, which first went to asterisk-users by mistake and
>     then was bounced by asterisk-devel because it exceeded 40 kb
>     (which is why I removed your mail from this reply, so hopefully
>     this one goes through). The key sentence was
>
>     "I think 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."
>
>     Regards
>     Enguerrand
>
>     ------------------------------------------------------------------------------------
>     Dipl.-Ing. Enguerrand de Rochefort
>     Softwareentwickler
>     mailto:eng...@el...
>     <mailto:eng...@el...>
>     Tel: +49-241-566266-72 <tel:%2B49-241-566266-72>
>     Fax: +49-241-566266-29 <tel:%2B49-241-566266-29>
>
>
>     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.
>
>     ------------------------------------------------------------------------------
>     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
>
>
>
> ------------------------------------------------------------------------------
> 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...
> 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

Re: [Asterisk-java-devel] 2.0 release

[Zoumana T. <zou...@gm...>]

Hello Brett,

Clearly, this is now clearer :-)
About your code suggestion: based on your return of experience (clear code,
easy to read and refactor, avoiding bugs) i don't have nothing against,
quite opposite if it can make our life (dev) easier :-)e

Zoumana


Le 19 avr. 2015 02:16, "Brett Sutton" <bs...@no...> a écrit :

>  So clearly I was very clear in my original post, so let me take a minute
> to clear things up so we have a clear view of where we are going.  Is that
> clear :)
>
> So the intent for 2.0 is that it will support version of Asterisk from 1.4
> to 13.
>
> There will be no need to run different versions of Asterisk java to
> support different version of asterisk.
>
> From the 3.0 version its probably worth think about culling some of the
> older versions, but this will depend on how hard it is to support the older
> versions.
>
> In the end the version that we support really comes down to what test
> environments we can managed to set up.
>
> As Enguerrand has suggested and as Stefan has down previously we can
> normally support both versions by mapping older legacy events actions to
> the new action/events.  We will obviously have to look into this on a case
> by case basis but I'm moderately confident that this can be managed. The
> only issue will be where an older version of asterisk doesn't support some
> of the attributes provided by the latest version.
>
> So hopefully that makes things a little clearer.
>
> Now my statements about breaking compatibility where not with respect to
> the version of asterisk. What I was talking about was the possibility of
> breaking the asterisk-java api compatibility in an effort to make the
> events/actions easier to use. The main idea being to replace channel and
> endpoint string in events and actions with actual classes.
>
> As an example the current LogChannelEvent has the following fields:
>
>    private String channel;
>     private Boolean enabled;
>     private Integer reason;
>     private String reasonTxt;
>
>
> These fields would be modified to be:
>
>    private iChannel channel;
>     private Boolean enabled;
>     private Integer reason;
>     private String reasonTxt;
>
> Where iChannel is an interface to a Channel implementation that provides a
> set of useful channel related operations.
>
> Our experience with doing the substitution is that interacting with
> asterisk becomes much easier, the code is easier to read and we eliminated
> a number of bugs at compile time.
>
> Have I made this clearer?
>
> What do people think about the idea of using classes for channels and
> endpoints rather than strings?
>
> Brett
>
>
>
> On 17/04/15 20:03, Zoumana TRAORE wrote:
>
> Hello everyone,
>
> Same as Enguerrand, IMHO we shoud consider keeping the backwards
> compatibility not forcing projects to have different code bases and builds
> processes...
>
> Regards,
> Zoumana
> Le 17 avr. 2015 10:07, "Enguerrand de Rochefort" <
> eng...@el...> a écrit :
>
>> Hi Brett
>>
>> I can say that
>> "it means that you have to have two different code bases to handle the
>> different versions of asterisk."
>> would not work for us. For a smooth  roll-out of Asterisk 13 we need to
>> support Asterisk 13 and all currently supported versions in parallel.
>>
>> That said, if I am the only one who sees it that way it should not affect
>> your decision on how to proceed, because I have already brought the current
>> codebase to a level that works with Asterisk 13 and Asterisk 1.4 in
>> parallel, so for us the problem is addressed, albeit in a way that only
>> covers the features our application actually makes use of. Anyways, I am
>> thinking that others might be in the same situation.
>>
>> This goes back to my previous mail regarding backward compatibility,
>> which first went to asterisk-users by mistake and then was bounced by
>> asterisk-devel because it exceeded 40 kb (which is why I removed your mail
>> from this reply, so hopefully this one goes through). The key sentence was
>>
>> "I think 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."
>>
>> Regards
>> Enguerrand
>>
>>
>> ------------------------------------------------------------------------------------
>> Dipl.-Ing. Enguerrand de Rochefort
>> Softwareentwickler
>> mailto:eng...@el...
>> Tel:  +49-241-566266-72
>> Fax: +49-241-566266-29
>>
>>
>> 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.
>>
>>
>> ------------------------------------------------------------------------------
>> 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...
>> https://lists.sourceforge.net/lists/listinfo/asterisk-java-devel
>>
>
>
> ------------------------------------------------------------------------------
> 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 exerciseshttp://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 lis...@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 Solutionswww.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-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/asterisk-java-devel
>
>

Re: [Asterisk-java-devel] 2.0 release

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

Hi Brett

to me this sounds very good. Would it make sense to make the transition a bit easier by adding a (possibly even deprecated) method to the iChannel interface that returns the String that would previously have been the channel representation?

So when I plug in the new asterisk-java lib I will get a ton of compile errors, but all I'll have to do in a first step to fix each of them is replacing "getChannel()" by "getChannel().getLegacyStringRepresentation()" or something similar?

Cheers
Enguerrand

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

Von: Brett Sutton [mailto:bs...@no...]
Gesendet: Sonntag, 19. April 2015 02:15
An: ast...@li...
Betreff: Re: [Asterisk-java-devel] 2.0 release

So clearly I was very clear in my original post, so let me take a minute to clear things up so we have a clear view of where we are going.  Is that clear :)

So the intent for 2.0 is that it will support version of Asterisk from 1.4 to 13.

There will be no need to run different versions of Asterisk java to support different version of asterisk.

>From the 3.0 version its probably worth think about culling some of the older versions, but this will depend on how hard it is to support the older versions.

In the end the version that we support really comes down to what test environments we can managed to set up.

As Enguerrand has suggested and as Stefan has down previously we can normally support both versions by mapping older legacy events actions to the new action/events.  We will obviously have to look into this on a case by case basis but I'm moderately confident that this can be managed. The only issue will be where an older version of asterisk doesn't support some of the attributes provided by the latest version.

So hopefully that makes things a little clearer.

Now my statements about breaking compatibility where not with respect to the version of asterisk. What I was talking about was the possibility of breaking the asterisk-java api compatibility in an effort to make the events/actions easier to use. The main idea being to replace channel and endpoint string in events and actions with actual classes.

As an example the current LogChannelEvent has the following fields:

   private String channel;
    private Boolean enabled;
    private Integer reason;
    private String reasonTxt;


These fields would be modified to be:

   private iChannel channel;
    private Boolean enabled;
    private Integer reason;
    private String reasonTxt;

Where iChannel is an interface to a Channel implementation that provides a set of useful channel related operations.

Our experience with doing the substitution is that interacting with asterisk becomes much easier, the code is easier to read and we eliminated a number of bugs at compile time.

Have I made this clearer?

What do people think about the idea of using classes for channels and endpoints rather than strings?

Brett



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.

Re: [Asterisk-java-devel] 2.0 release

[Brett S. <bs...@no...>]

yes that was exactly my thought process.


I've seen other projects die because a lack of backward compatibility 
between releases so I'm keen to avoid that death.




On 20/04/15 17:38, Enguerrand de Rochefort wrote:
>
> Hi Brett
>
> to me this sounds very good. Would it make sense to make the 
> transition a bit easier by adding a (possibly even deprecated) method 
> to the iChannel interface that returns the String that would 
> previously have been the channel representation?
>
> So when I plug in the new asterisk-java lib I will get a ton of 
> compile errors, but all I’ll have to do in a first step to fix each of 
> them is replacing “getChannel()” by 
> “getChannel().getLegacyStringRepresentation()” or something similar?
>
> Cheers
>
> Enguerrand
>
> ------------------------------------------------------------------------------------
>
> Dipl.-Ing. Enguerrand de Rochefort
>
> Softwareentwickler
>
> mailto:eng...@el...
>
> Tel: +49-241-566266-72
>
> Fax: +49-241-566266-29
>
> *Von:*Brett Sutton [mailto:bs...@no...]
> *Gesendet:* Sonntag, 19. April 2015 02:15
> *An:* ast...@li...
> *Betreff:* Re: [Asterisk-java-devel] 2.0 release
>
> So clearly I was very clear in my original post, so let me take a 
> minute to clear things up so we have a clear view of where we are 
> going.  Is that clear :)
>
> So the intent for 2.0 is that it will support version of Asterisk from 
> 1.4 to 13.
>
> There will be no need to run different versions of Asterisk java to 
> support different version of asterisk.
>
> >From the 3.0 version its probably worth think about culling some of 
> the older versions, but this will depend on how hard it is to support 
> the older versions.
>
> In the end the version that we support really comes down to what test 
> environments we can managed to set up.
>
> As Enguerrand has suggested and as Stefan has down previously we can 
> normally support both versions by mapping older legacy events actions 
> to the new action/events.  We will obviously have to look into this on 
> a case by case basis but I'm moderately confident that this can be 
> managed. The only issue will be where an older version of asterisk 
> doesn't support some of the attributes provided by the latest version.
>
> So hopefully that makes things a little clearer.
>
> Now my statements about breaking compatibility where not with respect 
> to the version of asterisk. What I was talking about was the 
> possibility of breaking the asterisk-java api compatibility in an 
> effort to make the events/actions easier to use. The main idea being 
> to replace channel and endpoint string in events and actions with 
> actual classes.
>
> As an example the current LogChannelEvent has the following fields:
>
>    private String channel;
>     private Boolean enabled;
>     private Integer reason;
>     private String reasonTxt;
>
>
> These fields would be modified to be:
>
>    private iChannel channel;
>     private Boolean enabled;
>     private Integer reason;
>     private String reasonTxt;
>
> Where iChannel is an interface to a Channel implementation that 
> provides a set of useful channel related operations.
>
> Our experience with doing the substitution is that interacting with 
> asterisk becomes much easier, the code is easier to read and we 
> eliminated a number of bugs at compile time.
>
> Have I made this clearer?
>
> What do people think about the idea of using classes for channels and 
> endpoints rather than strings?
>
> Brett
>
>
>
> 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.
>
>
> ------------------------------------------------------------------------------
> 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...
> 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

Re: [Asterisk-java-devel] 1.1 release

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

Hi Brett

so the only disadvantage I see with branching 1.1 from 1.0 is that if you'd ever want to do a bugfix/maintenance release on the 1.0 version (e.g. 1.0.1) this would become a bit messy.
That said, given how long there was a RC for 1.0 this might be a pretty theoretical problem.

Either way, I guess there will be a need to address this sooner or later, but I am by no means a git expert either, so maybe there is an elegant solution to this.
However, I don't know that I will be able to take over the merging tasks you suggested. To tell the truth, I was really only looking to contribute my code and was hoping for guidance as to how I should do it to minimize the work needed to incorporate it.

As I said earlier I have a couple of small patches here which I believe should probably go into 1.1 and then I have a couple of Asterisk 13 relevant changes which I would hold back until you guys start working on one of the later releases.

As soon as the respective branches for these two contributions are ready for it I would add the changes to them in my fork and send you a pull request.
Let me know if that makes sense?

Cheers
Enguerrand


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

-----Ursprüngliche Nachricht-----
Von: Brett Sutton [mailto:bs...@no...]
Gesendet: Mittwoch, 29. April 2015 06:29
An: ast...@li...
Betreff: Re: [Asterisk-java-devel] 1.1 release

Enguerrand,
so frankly I'm not certain of the best way to move forward.

Here are the issues as I see them (from a non git expert)

Reading up on branching strategies seems to imply that you normally branch from develop.

My concern with branching from develop, for 1.1, was that I'm not certain just how much code has been pushed into develop and of what quality it is. It may also have a fair amount of asterisk 11/13 code which 1.1 is not really about.

Going back to the wiki release notes, 1.1 is intended to only collect up small enhancments against 1.4, 1.6, and 1.8.

Having said that, the 11/13 code in develop is probably not harmful.

I note there there are also a number of outstanding pull requests that we need to resolve.
Would you be happy to have a look at merging those back into develop?

There are also a small no. of changes in 1.0 which won't be in develop.
Are you able to merge these into 1.1?

So the end result is that I'm prepared to be guided on this one.

If you think we can branch from develop and still get a stable release without massive amounts of effort then go ahead and branch from develop.

I've previously suggested that we should follow this model.

http://nvie.com/posts/a-successful-git-branching-model/

Brett



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.

Re: [Asterisk-java-devel] 1.1 release

[Brett S. <bs...@no...>]

So I've done some reading and it looks like we will be better off with 
branching 1.1 from master so I've done just that.

So go ahead and start merging your changes.

On 29/04/15 17:43, Enguerrand de Rochefort wrote:
> Hi Brett
>
> so the only disadvantage I see with branching 1.1 from 1.0 is that if you'd ever want to do a bugfix/maintenance release on the 1.0 version (e.g. 1.0.1) this would become a bit messy.
> That said, given how long there was a RC for 1.0 this might be a pretty theoretical problem.
>
> Either way, I guess there will be a need to address this sooner or later, but I am by no means a git expert either, so maybe there is an elegant solution to this.
> However, I don't know that I will be able to take over the merging tasks you suggested. To tell the truth, I was really only looking to contribute my code and was hoping for guidance as to how I should do it to minimize the work needed to incorporate it.
>
> As I said earlier I have a couple of small patches here which I believe should probably go into 1.1 and then I have a couple of Asterisk 13 relevant changes which I would hold back until you guys start working on one of the later releases.
>
> As soon as the respective branches for these two contributions are ready for it I would add the changes to them in my fork and send you a pull request.
> Let me know if that makes sense?
>
> Cheers
> Enguerrand
>
>
> ------------------------------------------------------------------------------------
> Dipl.-Ing. Enguerrand de Rochefort
> Softwareentwickler
> mailto:eng...@el...
> Tel:  +49-241-566266-72
> Fax: +49-241-566266-29
>
> -----Ursprüngliche Nachricht-----
> Von: Brett Sutton [mailto:bs...@no...]
> Gesendet: Mittwoch, 29. April 2015 06:29
> An: ast...@li...
> Betreff: Re: [Asterisk-java-devel] 1.1 release
>
> Enguerrand,
> so frankly I'm not certain of the best way to move forward.
>
> Here are the issues as I see them (from a non git expert)
>
> Reading up on branching strategies seems to imply that you normally branch from develop.
>
> My concern with branching from develop, for 1.1, was that I'm not certain just how much code has been pushed into develop and of what quality it is. It may also have a fair amount of asterisk 11/13 code which 1.1 is not really about.
>
> Going back to the wiki release notes, 1.1 is intended to only collect up small enhancments against 1.4, 1.6, and 1.8.
>
> Having said that, the 11/13 code in develop is probably not harmful.
>
> I note there there are also a number of outstanding pull requests that we need to resolve.
> Would you be happy to have a look at merging those back into develop?
>
> There are also a small no. of changes in 1.0 which won't be in develop.
> Are you able to merge these into 1.1?
>
> So the end result is that I'm prepared to be guided on this one.
>
> If you think we can branch from develop and still get a stable release without massive amounts of effort then go ahead and branch from develop.
>
> I've previously suggested that we should follow this model.
>
> http://nvie.com/posts/a-successful-git-branching-model/
>
> Brett
>
>
>
> 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.
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Asterisk-java-devel mailing list
> 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

Re: [Asterisk-java-devel] 1.1 release

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

Hi Brett

great, thanks. I sent you a pull request already. Let me know if you have any questions.

Cheers
Enguerrand

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

-----Ursprüngliche Nachricht-----
Von: Brett Sutton [mailto:bs...@no...]
Gesendet: Donnerstag, 30. April 2015 07:45
An: ast...@li...
Betreff: Re: [Asterisk-java-devel] 1.1 release

So I've done some reading and it looks like we will be better off with branching 1.1 from master so I've done just that.

So go ahead and start merging your changes.
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.

Re: [Asterisk-java-devel] 1.1 release

[Brett S. <bs...@no...>]

I've merge the pull request.

thanks

brett

On 30/04/15 19:49, Enguerrand de Rochefort wrote:
> Hi Brett
>
> great, thanks. I sent you a pull request already. Let me know if you have any questions.
>
> Cheers
> Enguerrand
>
> ------------------------------------------------------------------------------------
> Dipl.-Ing. Enguerrand de Rochefort
> Softwareentwickler
> mailto:eng...@el...
> Tel:  +49-241-566266-72
> Fax: +49-241-566266-29
>
> -----Ursprüngliche Nachricht-----
> Von: Brett Sutton [mailto:bs...@no...]
> Gesendet: Donnerstag, 30. April 2015 07:45
> An: ast...@li...
> Betreff: Re: [Asterisk-java-devel] 1.1 release
>
> So I've done some reading and it looks like we will be better off with branching 1.1 from master so I've done just that.
>
> So go ahead and start merging your changes.
> 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.
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Asterisk-java-devel mailing list
> 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

[Asterisk-java-devel] NOTICE: GitHUB URL change

[Brett S. <bs...@no...>]

Gentlefolk,
Stefan has just created a new github organisation 'asterisk-java' and 
has transferred the asterisk-java related repos from his personal 
account to the new organisational account.

The goood news  is that I can now help to administrator the repository.

Any questions please post to this list.

[Asterisk-java-devel] Asterisk-Java 1.0 release et al

[Martin D. <md...@du...>]

Here are my votes:

Issue 1
Put out 1.0 with NO FIXES.  Once people see some activity with the library,
they will be more likely to make pull/push requests.  Also, we could use
feedback from the 1.0 release to help prioritize additional work for 1.1

Issue 2
I think we should ask the developers first, but if they don't respond, then
I think you are correct and there is no alternative, but to do it ourselves.

Issue 3
We should target the features in 1.8 in the 1.X version.  This seems like a
popular version.  It is important to specify that I want to support the
feature set.  I am using the current version of asterisk-java against
version 13.3, but only using basic AMI and AGI features and it works well.
Claiming that we support 12 or 13 implies that there is support for ARI,
which would be it's own development effort.

Issue 4
We should target the features in 13+ in the 2.X version.  At some point,
ARI will have to either be in or out.  A more forward looking effort after
stabilizing the code base sounds like the time to do that.