Community |
Community.IRCmeeting20140924 HistoryShow minor edits - Show changes to output January 23, 2015, at 04:00 PM
by
- 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
- 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ăzvan's threads for today's discussion @] September 17, 2014, at 03:50 PM
by
- 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
- 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
- Added line 12:
TO ADD August 29, 2014, at 03:29 PM
by
- Added lines 1-18:
!!!!! Community -> [[Community/PublicMeetings | PublicMeetings]] -> 24th of September 2014 ---- !!!! Topics TODO ---- !!!! Conclusions ----- !!! IRC Logs TO ADD ----- |
Page last modified on January 23, 2015, at 04:00 PM