Community

Community.IRCmeeting20140924 History

Hide minor edits - Show changes to markup

January 23, 2015, at 04:00 PM by razvancrainea -
Changed line 27 from:

17:59 < razvanc> | Hi all!

to:

17:59 < razvanc>| Hi all!

Changed line 29 from:

18:00 < razvanc> | I'm great, looking forward to start the second public meeting

to:

18:00 < razvanc>| I'm great, looking forward to start the second public meeting

Changed line 31 from:

18:01 < razvanc> | I'll be the show maker today, since Bogdan is currently unavailable

to:

18:01 < razvanc>| I'll be the show maker today, since Bogdan is currently unavailable

Changed lines 33-37 from:

18:01 < razvanc> | :) 18:02 < razvanc> | so today we don't have a technical discussion 18:02 < razvanc> | what we want to discuss with you is the way the project will look from now on 18:03 < razvanc> | as Bogdan already described, we are first planning to rename the old OpenSIPS 2.0 to OpenSIPS Experimental 18:04 < razvanc> | since we are not planning to have a production ready OpenSIPS 2.0 any more

to:

18:01 < razvanc>| :) 18:02 < razvanc>| so today we don't have a technical discussion 18:02 < razvanc>| what we want to discuss with you is the way the project will look from now on 18:03 < razvanc>| as Bogdan already described, we are first planning to rename the old OpenSIPS 2.0 to OpenSIPS Experimental 18:04 < razvanc>| since we are not planning to have a production ready OpenSIPS 2.0 any more

Changed lines 39-40 from:

18:05 < razvanc> | but rather only use the current code for testing and experimental stuff 18:05 < razvanc> | what do you think about this?

to:

18:05 < razvanc>| but rather only use the current code for testing and experimental stuff 18:05 < razvanc>| what do you think about this?

Changed lines 43-45 from:

18:07 < razvanc> | hi lirakis 18:07 < razvanc> | yes, basically it is just a naming convention 18:07 < razvanc> | but this will allow us to use the OpenSIPS 2.x naming for further OpenSIPS releases

to:

18:07 < razvanc>| hi lirakis 18:07 < razvanc>| yes, basically it is just a naming convention 18:07 < razvanc>| but this will allow us to use the OpenSIPS 2.x naming for further OpenSIPS releases

Changed lines 47-49 from:

18:08 < razvanc> | no, not really 18:08 < razvanc> | the two projects will continue being separate 18:08 < razvanc> | but what we want to do is to import concepts from the current/old 2.0 to the main OpenSIPS project

to:

18:08 < razvanc>| no, not really 18:08 < razvanc>| the two projects will continue being separate 18:08 < razvanc>| but what we want to do is to import concepts from the current/old 2.0 to the main OpenSIPS project

Changed lines 51-52 from:

18:09 < razvanc> | yes, exactly 18:09 < razvanc> | well, that's the first step

to:

18:09 < razvanc>| yes, exactly 18:09 < razvanc>| well, that's the first step

Changed lines 56-57 from:

18:10 < razvanc> | yes, as liviuc says, the second step is to import several functionalities that were tested on the old 2.0 into the main branch 18:10 < razvanc> | thus creating the new OpenSIPS 2.x

to:

18:10 < razvanc>| yes, as liviuc says, the second step is to import several functionalities that were tested on the old 2.0 into the main branch 18:10 < razvanc>| thus creating the new OpenSIPS 2.x

Changed lines 61-62 from:

18:12 < razvanc> | yes, correct 18:13 < razvanc> | so, if there are no other objections, I'll consider everybody is happy with this :)

to:

18:12 < razvanc>| yes, correct 18:13 < razvanc>| so, if there are no other objections, I'll consider everybody is happy with this :)

Changed lines 68-70 from:

18:17 < razvanc> | ok, the next topic is related to the release policy 18:19 < razvanc> | what we are trying to do is to follow the linux model: have the unstable/beta versions labeled with odd minors (2.1, 2.3, etc.) and the stable versions with even numbers (2.2, 2.4, etc.) 18:20 < razvanc> | this way the OpenSIPS status will be clear for everybody

to:

18:17 < razvanc>| ok, the next topic is related to the release policy 18:19 < razvanc>| what we are trying to do is to follow the linux model: have the unstable/beta versions labeled with odd minors (2.1, 2.3, etc.) and the stable versions with even numbers (2.2, 2.4, etc.) 18:20 < razvanc>| this way the OpenSIPS status will be clear for everybody

Changed line 72 from:

18:21 < razvanc> | do you happen to know the reason why they removed this?

to:

18:21 < razvanc>| do you happen to know the reason why they removed this?

Changed line 75 from:

18:24 < razvanc> | we thought it is worth proposing this scheme because it is easier to manage the opensips version status

to:

18:24 < razvanc>| we thought it is worth proposing this scheme because it is easier to manage the opensips version status

Changed lines 79-81 from:

18:27 < razvanc> | not really 18:27 < razvanc> | LTSs are released every two years iirc 18:28 < razvanc> | so not all even versions will be LTS

to:

18:27 < razvanc>| not really 18:27 < razvanc>| LTSs are released every two years iirc 18:28 < razvanc>| so not all even versions will be LTS

Changed lines 85-88 from:

18:32 < razvanc> | so we should have releases for odd numbers too, but only STS 18:32 < razvanc> | and all even should be LTS 18:32 < razvanc> | that would be interesting 18:32 < razvanc> | it would be even more clear what kind of version you're using

to:

18:32 < razvanc>| so we should have releases for odd numbers too, but only STS 18:32 < razvanc>| and all even should be LTS 18:32 < razvanc>| that would be interesting 18:32 < razvanc>| it would be even more clear what kind of version you're using

Changed lines 90-100 from:

18:33 < razvanc> | I think it's a subject that worths involving more people 18:34 < razvanc> | and I will open a thread on the lists related to this 18:34 < razvanc> | and we should continue the discussion over there 18:34 < razvanc> | meanwhile, let's proceed to the next topic 18:34 < razvanc> | the realising timing 18:35 < razvanc> | currently we are releasing a version every 6 months 18:35 < razvanc> | this means that for each version, we have around 4 months for developing and 2 months for testing 18:35 < razvanc> | we find this time quite short 18:36 < razvanc> | moreover having more releases means bigger migration efforts 18:36 < razvanc> | that's why we would like to increase the release time from 6 to 12 months 18:37 < razvanc> | any thoughts about that?

to:

18:33 < razvanc>| I think it's a subject that worths involving more people 18:34 < razvanc>| and I will open a thread on the lists related to this 18:34 < razvanc>| and we should continue the discussion over there 18:34 < razvanc>| meanwhile, let's proceed to the next topic 18:34 < razvanc>| the realising timing 18:35 < razvanc>| currently we are releasing a version every 6 months 18:35 < razvanc>| this means that for each version, we have around 4 months for developing and 2 months for testing 18:35 < razvanc>| we find this time quite short 18:36 < razvanc>| moreover having more releases means bigger migration efforts 18:36 < razvanc>| that's why we would like to increase the release time from 6 to 12 months 18:37 < razvanc>| any thoughts about that?

Changed line 102 from:

18:40 < razvanc> | yes, sure

to:

18:40 < razvanc>| yes, sure

Changed line 104 from:

18:42 < razvanc> | for major releases?

to:

18:42 < razvanc>| for major releases?

Changed line 106 from:

18:42 < razvanc> | roughly

to:

18:42 < razvanc>| roughly

Changed lines 108-109 from:

18:43 < razvanc> | yes, minor releases don't get new features 18:43 < razvanc> | only bug fixes

to:

18:43 < razvanc>| yes, minor releases don't get new features 18:43 < razvanc>| only bug fixes

Changed lines 111-112 from:

18:43 < razvanc> | and minor releases can be done anytime 18:43 < razvanc> | yes, only major releases are scheduled every year

to:

18:43 < razvanc>| and minor releases can be done anytime 18:43 < razvanc>| yes, only major releases are scheduled every year

Changed line 119 from:

18:47 < razvanc> | capncrunch4me: that's something we should have in mind for the next summit sessions

to:

18:47 < razvanc>| capncrunch4me: that's something we should have in mind for the next summit sessions

Changed line 121 from:

18:49 < razvanc> | sure let's move this on the list too

to:

18:49 < razvanc>| sure let's move this on the list too

Changed line 123 from:

18:51 < razvanc> | usually people prefer stability over innovation

to:

18:51 < razvanc>| usually people prefer stability over innovation

Changed line 125 from:

18:51 < razvanc> | having more time for testing, means better stability for production platform

to:

18:51 < razvanc>| having more time for testing, means better stability for production platform

Changed line 127 from:

18:51 < razvanc> | however, as liviuc said, one can always backport an interesting feaure it desperately needs

to:

18:51 < razvanc>| however, as liviuc said, one can always backport an interesting feaure it desperately needs

Changed line 130 from:

18:53 < razvanc> | :) I agree

to:

18:53 < razvanc>| :) I agree

Changed line 132 from:

18:54 < razvanc> | that's true :D

to:

18:54 < razvanc>| that's true :D

Changed line 135 from:

18:54 < razvanc> | and it is something we encourage

to:

18:54 < razvanc>| and it is something we encourage

Changed line 138 from:

18:55 < razvanc> | yes

to:

18:55 < razvanc>| yes

Changed line 144 from:

18:59 < razvanc> | not really, it is not such a hard work to do a release every once in a while

to:

18:59 < razvanc>| not really, it is not such a hard work to do a release every once in a while

Changed lines 146-148 from:

19:01 < razvanc> | we believed that increasing the time for delopment and testing would increase the stability of the code 19:01 < razvanc> | and we would also reduce the amount of work spent on migration 19:01 < razvanc> | anyway, this is not something we settled, that's why we're having it as a topic

to:

19:01 < razvanc>| we believed that increasing the time for delopment and testing would increase the stability of the code 19:01 < razvanc>| and we would also reduce the amount of work spent on migration 19:01 < razvanc>| anyway, this is not something we settled, that's why we're having it as a topic

Changed lines 150-151 from:

19:02 < razvanc> | to discuss and gather your opinions :) 19:02 < razvanc> | so let's see what others have to say about this

to:

19:02 < razvanc>| to discuss and gather your opinions :) 19:02 < razvanc>| so let's see what others have to say about this

Changed line 153 from:

19:03 < razvanc> | will open a thread about this too on the mailing list

to:

19:03 < razvanc>| will open a thread about this too on the mailing list

Changed line 155 from:

19:03 < razvanc> | anything else to add? any other thoughts, remarks or suggestions related to the topics we've discussed today?

to:

19:03 < razvanc>| anything else to add? any other thoughts, remarks or suggestions related to the topics we've discussed today?

Changed line 158 from:

19:05 < razvanc> | I would too, but it seems everybody is busy

to:

19:05 < razvanc>| I would too, but it seems everybody is busy

Changed line 160 from:

19:05 < razvanc> | discussing this on the mailing list would offer them more time to think

to:

19:05 < razvanc>| discussing this on the mailing list would offer them more time to think

Changed lines 165-167 from:

19:07 < razvanc> | that's something bogdan is working for a while and we are planning to release it as soon as possible 19:08 < razvanc> | we'll still have some interim releases with it, don't worry 19:08 < razvanc> | but not stable ones

to:

19:07 < razvanc>| that's something bogdan is working for a while and we are planning to release it as soon as possible 19:08 < razvanc>| we'll still have some interim releases with it, don't worry 19:08 < razvanc>| but not stable ones

Changed lines 170-172 from:

19:09 < razvanc> | meaning that we won't offer LTS support for them, until they are properly tested - and this takes time 19:09 < razvanc> | that would be great, thanks for offering! 19:10 < razvanc> | so if nobody has anything else to add, we can close the meeting here

to:

19:09 < razvanc>| meaning that we won't offer LTS support for them, until they are properly tested - and this takes time 19:09 < razvanc>| that would be great, thanks for offering! 19:10 < razvanc>| so if nobody has anything else to add, we can close the meeting here

Changed lines 174-175 from:

19:10 < razvanc> | thank you very much for joining! 19:11 < razvanc> | we really appreciate your input and will definitely consider it for our next discussion

to:

19:10 < razvanc>| thank you very much for joining! 19:11 < razvanc>| we really appreciate your input and will definitely consider it for our next discussion

Changed line 177 from:

19:12 < razvanc> | I will post the conclusions of this meeting on the website tomorrow and open the two threads we discussed

to:

19:12 < razvanc>| I will post the conclusions of this meeting on the website tomorrow and open the two threads we discussed

September 25, 2014, at 11:12 AM by razvancrainea -
Changed lines 18-20 from:

TO ADD

to:
  • Renaming the old OpenSIPS 2.0 to OpenSIPS Experimental is a good idea because it will give us more flexibility when naming future releases of the main OpenSIPS project
  • This release naming scheme will provide more information about the status of the version in use, whether it is a beta/unstable or stable one.
  • Although this increases the time for developing and testing new features in OpenSIPS, it also increases the time new functions are released. Brett suggested that we should keep the current release scheme. We will continue this discussion over the mailing list: TODO?.
Changed lines 26-179 from:

TO ADD

to:
17:59 <     razvanc> | Hi all!
18:00 < capncrunch4>| hey razvan, how are you
18:00 <     razvanc> | I'm great, looking forward to start the second public meeting
18:00 < capncrunch4>| are you running the show today or is Bogdan?
18:01 <     razvanc> | I'll be the show maker today, since Bogdan is currently unavailable
18:01 <      saghul>| ohai!
18:01 <     razvanc> | :)
18:02 <     razvanc> | so today we don't have a technical discussion
18:02 <     razvanc> | what we want to discuss with you is the way the project will look from now on
18:03 <     razvanc> | as Bogdan already described, we are first planning to rename the old OpenSIPS 2.0 to OpenSIPS Experimental
18:04 <     razvanc> | since we are not planning to have a production ready OpenSIPS 2.0 any more
18:04 < capncrunch4>| ok
18:05 <     razvanc> | but rather only use the current code for testing and experimental stuff
18:05 <     razvanc> | what do you think about this?
18:07 < capncrunch4>| Im confused, is this just a naming convention thing? I mean, you are kind of already doing this
18:07 <     lirakis>| helo
18:07 <     razvanc> | hi lirakis 
18:07 <     razvanc> | yes, basically it is just a naming convention
18:07 <     razvanc> | but this will allow us to use the OpenSIPS 2.x naming for further OpenSIPS releases
18:07 < capncrunch4>| so are you planning on merging head and 2.0 to create experimental?
18:08 <     razvanc> | no, not really
18:08 <     razvanc> | the two projects will continue being separate 
18:08 <     razvanc> | but what we want to do is to import concepts from the current/old 2.0 to the main OpenSIPS project
18:09 < capncrunch4>| so it is purely naming convention. Makes sense to me.
18:09 <     razvanc> | yes, exactly
18:09 <     razvanc> | well, that's the first step
18:09 < capncrunch4>| i mean…it would be silly to be opensips 1.9999
18:09 <      liviuc>| not just naming! there will be a significant shift in design from OpenSIPS 1.x to 2.x
18:10 <      liviuc>| however, not as drastic as the current 2.0 is right now
18:10 <     razvanc> | yes, as liviuc says, the second step is to import several functionalities that were tested on the old 2.0 into the main branch
18:10 <     razvanc> | thus creating the new OpenSIPS 2.x
18:11 < capncrunch4>| makes sense…it a way to make more incremental growth in naming without creeping up against that 2.0 barrier
18:11 < capncrunch4>| and allows 2.0 to be more of an interim release
18:11 < capncrunch4>| (thumbsup)
18:12 <     razvanc> | yes, correct
18:13 <     razvanc> | so, if there are no other objections, I'll consider everybody is happy with this :)
18:13 < capncrunch4>| silence is golden
18:13 <      liviuc>| it is a lot easier for us as developers to manage the projects as well
18:13 <      liviuc>| it is quite hard to push both projects with the man-power we currently have
18:15 <      liviuc>| so, rather than letting great ideas not getting tested at all (current 2.0 design)
18:16 <      liviuc>| we feel the need to just import some of them into a fresh new OpenSIPS :)
18:17 <     razvanc> | ok, the next topic is related to the release policy
18:19 <     razvanc> | what we are trying to do is to follow the linux model: have the unstable/beta versions labeled with odd minors (2.1, 2.3, etc.) and the stable versions with even numbers (2.2, 2.4, etc.)
18:20 <     razvanc> | this  way the OpenSIPS status will be clear for everybody
18:20 < capncrunch4>| that may have been true up until 3.x linux….then that kinda goes out the door
18:21 <     razvanc> | do you happen to know the reason why they removed this?
18:22 < capncrunch4>| not really, there is alot of btrfs development going on in the kernel right now. Alot of that is driving versioning numbers
18:23 < capncrunch4>| but you are right in the odd/even numbering. It just isnt quite following the actual purpose of it right now, due to the aggressive filesystem development being done
18:24 <     razvanc> | we thought it is worth proposing this scheme because it is easier to manage the opensips version status
18:24 < capncrunch4>| im cool with odd/even versioning though on naming convention
18:25 < capncrunch4>| or numbering convention, rather
18:25 < capncrunch4>| so each even will be LTS?
18:27 <     razvanc> | not really
18:27 <     razvanc> | LTSs are released every two years iirc
18:28 <     razvanc> | so not all even versions will be LTS
18:30 < capncrunch4>| again, they are doing away with that in 3.x
18:30 < capncrunch4>| .10, .12, .14, .16 are all LTS in 3.x kernel
18:31 < capncrunch4>| are you planning on doing odd/even numbering and then doing ad-hoc LTS support
18:32 <     razvanc> | so we should have releases for odd numbers too, but only STS
18:32 <     razvanc> | and all even should be LTS
18:32 <     razvanc> | that would be interesting
18:32 <     razvanc> | it would be even more clear what kind of version you're using
18:33 < capncrunch4>| yeah
18:33 <     razvanc> | I think it's a subject that worths involving more people
18:34 <     razvanc> | and I will open a thread on the lists related to this
18:34 <     razvanc> | and we should continue the discussion over there
18:34 <     razvanc> | meanwhile, let's proceed to the next topic
18:34 <     razvanc> | the realising timing
18:35 <     razvanc> | currently we are releasing a version every 6 months
18:35 <     razvanc> | this means that for each version, we have around 4 months for developing and 2 months for testing
18:35 <     razvanc> | we find this time quite short
18:36 <     razvanc> | moreover having more releases means bigger migration efforts
18:36 <     razvanc> | that's why we would like to increase the release time from 6 to 12 months
18:37 <     razvanc> | any thoughts about that?
18:39 < capncrunch4>| so between releases, it will just be minor version numbers for bugfixes, etc.
18:40 <     razvanc> | yes, sure
18:41 < capncrunch4>| I feel like a year is a lifetime
18:42 <     razvanc> | for major releases?
18:42 < capncrunch4>| would it be 9 mos of dev and 3 mos of testing/migration?
18:42 <     razvanc> | roughly
18:42 < capncrunch4>| for major releases, yearly seems ok. Are you suggesting no features go into the minor releases?
18:43 <     razvanc> | yes, minor releases don't get new features
18:43 <     razvanc> | only bug fixes
18:43 < capncrunch4>| so new features get released every year
18:43 <     razvanc> | and minor releases can be done anytime
18:43 <     razvanc> | yes, only major releases are scheduled every year
18:44 < capncrunch4>| i suspect you will get pushback here from the community
18:44 <      liviuc>| the "yearly feature" party doesn't seem like a problem to me
18:45 < capncrunch4>| that suggests things like async will not be available until October 2015
18:45 < capncrunch4>| or other modules
18:45 <      liviuc>| if there is a really important feature that people could use, they could backport it and rebuild from code
18:46 < capncrunch4>| if you were to coordinate major releases with opensips summits, that would somewhat make sense
18:47 <     razvanc> | capncrunch4me: that's something we should have in mind for the next summit sessions
18:48 < capncrunch4>| I still think 1/2’ing the release cadence will get some pushback. I would suggest soliciting feedback from the list
18:49 <     razvanc> | sure let's move this on the list too
18:50 < capncrunch4>| my only concern would be allowing the project to be out innovated by similar projects due to release cadence
18:51 <     razvanc> | usually people prefer stability over innovation
18:51 < capncrunch4>| and while you are suggesting that you take a more incremental approach to the version numbers, you are actually going backwards on release cadence
18:51 <     razvanc> | having more time for testing, means better stability for production platform
18:51 < capncrunch4>| i agree and disagree
18:51 <     razvanc> | however, as liviuc said, one can always backport an interesting feaure it desperately needs
18:51 < capncrunch4>| testing in a vacuum is simply that, ie valgrind can only take you so far
18:53 < capncrunch4>| i say that having broken every stable opensips release and subrelease for the past 2 years
18:53 <     razvanc> | :) I agree
18:54 < capncrunch4>| i mean opensips is community supported, which means it is our job to break it ;)
18:54 <     razvanc> | that's true :D
18:54 < capncrunch4>| and we can break it in ways that arent available in a development environment
18:54 <      liviuc>| if only that would happen more often!
18:54 <     razvanc> | and it is something we encourage
18:55 < capncrunch4>| alright, so lets distill this down a bit
18:55 < capncrunch4>| this is all about setting expectations, right? The naming, the release cadence, etc.
18:55 <     razvanc> | yes
18:56 < capncrunch4>| I can tell you that from my perspective, Opensips is the best of breed as far as stability. It has taken that approach as a primary differentiator from something like Kamailion
18:56 < capncrunch4>| Kamailio
18:57 < capncrunch4>| you are suggesting that what you are current doing isnt working with 6 mos releases. I would argue otherwise.
18:58 < capncrunch4>| so, this feels like it is being motivated by something else. Are the maintainers burning out?
18:59 < capncrunch4>| it has also been my experience that more smaller iterations are much better than large iterations from a QC perspective
18:59 <     razvanc> | not really, it is not such a hard work to do a release every once in a while
18:59 < capncrunch4>| so why fix what isnt broken?
19:01 <     razvanc> | we believed that increasing the time for delopment and testing would increase the stability of the code
19:01 <     razvanc> | and we would also reduce the amount of work spent on migration
19:01 <     razvanc> | anyway, this is not something we settled, that's why we're having it as a topic
19:01 < capncrunch4>| sure, I just wanted to paint the picture for you
19:02 <     razvanc> | to discuss and gather your opinions :)
19:02 <     razvanc> | so let's see what others have to say about this
19:02 < capncrunch4>| sure! open dialog is great here
19:03 <     razvanc> | will open a thread about this too on the mailing list
19:03 < capncrunch4>| cool
19:03 <     razvanc> | anything else to add? any other thoughts, remarks or suggestions related to the topics we've discussed today?
19:03 < capncrunch4>| By the way, I am standing in as a proxy for brettnem on this discussion (hence why you probably dont recognize my handle).
19:05 < capncrunch4>| im cool, just wish there were more on here to weigh in. I suspect you will get alot more traction on the lists
19:05 <     razvanc> | I would too, but it seems everybody is busy
19:05 < capncrunch4>| yeah
19:05 <     razvanc> | discussing this on the mailing list would offer them more time to think
19:06 < capncrunch4>| yeap
19:06 < capncrunch4>| im super interested in the async stuff. Its kind of a driver for us, since the scale we operate at kind of requires it. Even to the point of bolting kamailio to the back of opensips just for database calls
19:06 < capncrunch4>| which……sucks.
19:07 < capncrunch4>| so hearing that it may be another year before it would be ready (due to yearly release cadences), it has me screaming NOOOO!!!
19:07 <     razvanc> | that's something bogdan is working for a while and we are planning to release it as soon as possible
19:08 <     razvanc> | we'll still have some interim releases with it, don't worry
19:08 <     razvanc> | but not stable ones
19:08 < capncrunch4>| yeah
19:08 < capncrunch4>| well if you need someone to test it, brettnem can certainly volunteer our 8k cps of production traffic at it
19:09 <     razvanc> | meaning that we won't offer LTS support for them, until they are properly tested - and this takes time
19:09 <     razvanc> | that would be great, thanks for offering!
19:10 <     razvanc> | so if nobody has anything else to add, we can close the meeting here
19:10 < capncrunch4>| im good
19:10 <     razvanc> | thank you very much for joining!
19:11 <     razvanc> | we really appreciate your input and will definitely consider it for our next discussion
19:11 <      liviuc>| thank you!
19:12 <     razvanc> | I will post the conclusions of this meeting on the website tomorrow and open the two threads we discussed
19:12 <      liviuc>| make sure to reply on the list to R&#259;zvan's threads for today's discussion
September 17, 2014, at 03:50 PM by razvancrainea -
Changed line 8 from:
  • Old OpenSIPS 2.0 will become OpenSIPS Experimental. It will never be released, but only used as a playground for testing new concepts. All the validated concepts will be upgraded to the main OpenSIPS project.
to:
  • Old OpenSIPS 2.0 will become OpenSIPS Experimental. It will never be released, but only used as a playground for testing new concepts. All the validated concepts will be imported to the main OpenSIPS project.
September 17, 2014, at 03:39 PM by razvancrainea -
Changed lines 6-12 from:

TODO

to:

OpenSIPS 2.0

  • Old OpenSIPS 2.0 will become OpenSIPS Experimental. It will never be released, but only used as a playground for testing new concepts. All the validated concepts will be upgraded to the main OpenSIPS project.
  • Release policy
    • the odd versions will be reserved for unstable/beta versions (i.e. the current OpenSIPS 1.12[trunk] will become OpenSIPS 2.1[trunk/devel])
    • the stable released versions will get only even numbers - next stable release will be OpenSIPS 2.2
  • Release timing: the release cycle should be increased from 6 to 12 months. This provides the community more time for testing and developing new features between releases and reduces the frequency of upgrades.
August 29, 2014, at 03:29 PM by razvancrainea -
Added line 12:

TO ADD

August 29, 2014, at 03:29 PM by razvancrainea -
Added lines 1-18:
Community -> PublicMeetings -> 24th of September 2014

Topics

TODO


Conclusions


IRC Logs

TO ADD



Page last modified on January 23, 2015, at 04:00 PM