download link broken on apr.apache.org
click on Download goes to http://apr.apache.org/download.cgi, and return a 500 Internal Server Error. Thanks.
Re: download link broken on apr.apache.org
The .cgi was chmod`ed 664... no execute bit. Fixed now. Seems to be working for me. -Paul C K Tan wrote: click on Download goes to http://apr.apache.org/download.cgi, and return a 500 Internal Server Error. Thanks.
Backport and release policy for APR and APR-UTIL...
What is the backport and release policy for APR and APR-UTIL? I assume that the APR and APR-UTIL projects have adopted the same RTC/STATUS file voting policy as the HTTPD project. Assuming that this is true, there appears to be a break down in how this policy functions in the APR projects. It's been a couple of months since the release of APR 1.0. Since then there has been a lot of activity in TRUNK as compared to almost no activity in the 1.0.x branch. So the question is, have all of the patches committed to TRUNK truely been 1.1.x only patches or should a portion of them have been backported to the 1.0.x branch? Either way this question is answered brings up some concerns about the future of APR and APR-UTIL projects. If the answer is yes then how long will it be before we see APR 1.2? Given the previous history of the HTTPD project moving from one point release to another, it could be a couple of years before we see 1.2. This would mean that a lot of good work and valuable patches will be going unnoticed and untested in the community for a very long time. Kind of flys in the face of Release Early, Release Often. If the answer is no then why haven't they been backported so that we can get these code changes tested and put to good use quickly? If we have adopted the RTC/STATUS file voting policy, then we need to start using it and start working towards the 1.02, 1.0.3, 1.0.4, etc. releases. Otherwise it appears that APR and APR-UTIL will eventually stagnate due to the fact that any work that is done, never gets released or used. Thoughts? Brad
Re: SVN list?
André Malo wrote: * Julian Foad wrote: Can you fix the web page? Done. Thanks. - Julian
Re: Backport and release policy for APR and APR-UTIL...
On Wed, 15 Dec 2004, Brad Nicholes wrote: release of APR 1.0. Since then there has been a lot of activity in TRUNK as compared to almost no activity in the 1.0.x branch. After the 1.0.x branch was created at ApacheCon, Justin and Thom backported everything that they thought could be backported without breaking binary compatibility... --Cliff
Re: Backport and release policy for APR and APR-UTIL...
Where all of the backports included in the CHANGES file for version 1.0.1? What about any work that has been done since 1.0.1? There still aren't sections in the STATUS files for listing and voting on backports and I just recently added a Changes for APR 1.0.2 in the APR changes file because of a NetWare issue. Should I go ahead and fix up the APR and APR-UTIL STATUS and CHANGES files with the appropriate sections? Maybe I missed it, but I am just not sure that the ground rules for the APR and APR-UTIL projects have set like they were with HTTPD. Just making sure that at least my assumptions about how we proceed are correct. Brad Cliff Woolley [EMAIL PROTECTED] Wednesday, December 15, 2004 11:29 AM On Wed, 15 Dec 2004, Brad Nicholes wrote: release of APR 1.0. Since then there has been a lot of activity in TRUNK as compared to almost no activity in the 1.0.x branch. After the 1.0.x branch was created at ApacheCon, Justin and Thom backported everything that they thought could be backported without breaking binary compatibility... --Cliff
Re: Backport and release policy for APR and APR-UTIL...
Ok, you have me confused :) There can be no binary breakage between 1.0.0 and 1.99.999. Nothing (except for unreleased changes in our svn repository) as we move forward. Minor bumps introduce new features. Subversion bumps fix bugs. That's the short story. I'm increasing concerned that folks believe that we won't go to 1.1 or 2.0 until there is some magic 'httpd' project release. Nothing is farther from the truth. APR and APR-UTIL will be released as we have improvements that are stable. If the httpd, svn, foo, bash or bang projects want to use a specific version that is fine. Moving forward, httpd may decide to 'officially' move from version 1.1 to 1.3, for example, between their 2.2.0 and 2.2.4 releases. That's allowed by both project's compatibility rules. Nothing is changing that breaks code compiled for apr 1.1 or httpd 2.2.0 when a user moves up to 1.3 and 2.2.4. Where projects with strong binary bindings get trapped, is when they want to jump from APR 1.x to 2.x (or straight to 3.x skipping our 2.x releases.) We've assured our users that APR won't break compatibility until they jump major version. So the httpd project will prod us to continue to bug fix both apr 0.x, and apr 1.x, once they have released some httpd that is based on 1.x (if they do.) That's understandable. But asking about backporting from 1.1.x to 1.0.x seems somewhat silly. Bill At 12:29 PM 12/15/2004, Cliff Woolley wrote: On Wed, 15 Dec 2004, Brad Nicholes wrote: release of APR 1.0. Since then there has been a lot of activity in TRUNK as compared to almost no activity in the 1.0.x branch. After the 1.0.x branch was created at ApacheCon, Justin and Thom backported everything that they thought could be backported without breaking binary compatibility... --Cliff
Re: Backport and release policy for APR and APR-UTIL...
That's understandable. But asking about backporting from 1.1.x to 1.0.x seems somewhat silly. The reason why it's *not* silly is because of our release schedules. Unless the APR project wants to do something completely different with versioning, revision releases (1.0.1 to 1.0.2) are usually on the order of a few months. Point releases (1.0.x to 1.2.x assuming even numbered releases) are usually on the order of years. Major releases (1.x to 2.x) are on the order of who knows when. That has been the history of HTTPD and I don't see any reason why it wouldn't be the history for APR as well. Given that assumption, I don't want to wait a year for APR 1.2 to be released just to see a minor bug fixed. I want it backported to 1.0.x so that it gets released next month (or sooner). Also using HTTPD as an example, HTTPD 2.2 will not be binary compatible with 2.0. We have already made sure of that with a magic number bump. Therefore, I don't see why APR 1.2.x must be binary compatible with 1.0.x. Brad William A. Rowe, Jr. [EMAIL PROTECTED] Wednesday, December 15, 2004 2:14 PM Ok, you have me confused :) There can be no binary breakage between 1.0.0 and 1.99.999. Nothing (except for unreleased changes in our svn repository) as we move forward. Minor bumps introduce new features. Subversion bumps fix bugs. That's the short story. I'm increasing concerned that folks believe that we won't go to 1.1 or 2.0 until there is some magic 'httpd' project release. Nothing is farther from the truth. APR and APR-UTIL will be released as we have improvements that are stable. If the httpd, svn, foo, bash or bang projects want to use a specific version that is fine. Moving forward, httpd may decide to 'officially' move from version 1.1 to 1.3, for example, between their 2.2.0 and 2.2.4 releases. That's allowed by both project's compatibility rules. Nothing is changing that breaks code compiled for apr 1.1 or httpd 2.2.0 when a user moves up to 1.3 and 2.2.4. Where projects with strong binary bindings get trapped, is when they want to jump from APR 1.x to 2.x (or straight to 3.x skipping our 2.x releases.) We've assured our users that APR won't break compatibility until they jump major version. So the httpd project will prod us to continue to bug fix both apr 0.x, and apr 1.x, once they have released some httpd that is based on 1.x (if they do.) That's understandable. But asking about backporting from 1.1.x to 1.0.x seems somewhat silly. Bill At 12:29 PM 12/15/2004, Cliff Woolley wrote: On Wed, 15 Dec 2004, Brad Nicholes wrote: release of APR 1.0. Since then there has been a lot of activity in TRUNK as compared to almost no activity in the 1.0.x branch. After the 1.0.x branch was created at ApacheCon, Justin and Thom backported everything that they thought could be backported without breaking binary compatibility... --Cliff
Re: Backport and release policy for APR and APR-UTIL...
Brad Nicholes wrote: That's understandable. But asking about backporting from 1.1.x to 1.0.x seems somewhat silly. The reason why it's *not* silly is because of our release schedules. Unless the APR project wants to do something completely different with versioning, revision releases (1.0.1 to 1.0.2) are usually on the order of a few months. Point releases (1.0.x to 1.2.x assuming even numbered releases) are usually on the order of years. Major releases (1.x to 2.x) are on the order of who knows when. That has been the history of HTTPD and I don't see any reason why it wouldn't be the history for APR as well. Given that assumption, I don't want to wait a year for APR 1.2 to be released just to see a minor bug fixed. I want it backported to 1.0.x so that it gets released next month (or sooner). Also using HTTPD as an example, HTTPD 2.2 will not be binary compatible with 2.0. We have already made sure of that with a magic number bump. Therefore, I don't see why APR 1.2.x must be binary compatible with 1.0.x. Brad Eh? APR does not have the same versioning policy as HTTPD. http://apr.apache.org/versioning.html I am thinking it might be a good idea todo a 1.1.0 release before httpd-2.2. Lets just do it. Whats stopping a 1.1.0 release today? I don't see any big issues, so, someone needs to take charge as a release manager and make it happen. -Paul Querna
Re: Backport and release policy for APR and APR-UTIL...
At 04:31 PM 12/15/2004, Paul Querna wrote: Brad Nicholes wrote: The reason why it's *not* silly is because of our release schedules. Unless the APR project wants to do something completely different with versioning, revision releases (1.0.1 to 1.0.2) are usually on the order of a few months. Point releases (1.0.x to 1.2.x assuming even numbered releases) are usually on the order of years. Major releases (1.x to 2.x) are on the order of who knows when. That has been the history of HTTPD and I don't see any reason why it wouldn't be the history for APR as well. I hope we -don't- try to model httpd. A library such as apr is substantially different than httpd. Given that assumption, I don't want to wait a year for APR 1.2 to be released just to see a minor bug fixed. I want it backported to 1.0.x so that it gets released next month (or sooner). Also using HTTPD as an example, HTTPD 2.2 will not be binary compatible with 2.0. We have already made sure of that with a magic number bump. Therefore, I don't see why APR 1.2.x must be binary compatible with 1.0.x. Because those are our versioning rules... please review them. Although httpd can change it's rules to suit the project, those who adopt the apr library have based their decisions on the rules we had laid down and already voted on. We absolutely cannot break binary compatibility until the next major rev. If that means that apr is 10.1.0 in two years, so be it. I am thinking it might be a good idea todo a 1.1.0 release before httpd-2.2. Or 2.0 - if we actually fix the alignment issues. Lets just do it. Whats stopping a 1.1.0 release today? I don't see any big issues, so, someone needs to take charge as a release manager and make it happen. +1 if 1.1 includes new features, and STATUS showstoppers are closed. hint description=If you have a 1.1 issue, add it to STATUS / Bill
Re: Backport and release policy for APR and APR-UTIL...
On Wed, Dec 15, 2004 at 01:29:02PM -0500, Cliff Woolley wrote: On Wed, 15 Dec 2004, Brad Nicholes wrote: release of APR 1.0. Since then there has been a lot of activity in TRUNK as compared to almost no activity in the 1.0.x branch. After the 1.0.x branch was created at ApacheCon, Justin and Thom backported everything that they thought could be backported without breaking binary compatibility... Correct. I don't think we need to have as strict an RTC policy as httpd - but the only issue is that any change that is backported can not break binary compatibility at *all*. Bumping the minor version (1.0-1.1) can add new functions, but it can't change any existing functions at all. And, bumping the major version (i.e. 2.0) causes all bets to be off. =) -- justin
Re: Backport and release policy for APR and APR-UTIL...
I stand corrected on versioning. This was actually some of the information that I was looking for and just missed somehow. But I think that this brings up another issue that I am still confused about. We have already created a 1.0.x branch. Does this mean that we are going to be creating a lot more short-lived branches? I assume that when we go to 1.1 we will be creating a new branch and so forth with 1.2 etc. I also don't see how we are separating incompatible patches from compatible patches if everything is going into TRUNK and there is no where to backport. It seems like we should have created a 1.x branch rather than a 1.0.x branch and backported from TRUNK to 1.x. The versioning rules don't change the fact that we don't have a way of moving forward with a stable release branch vs. an unstable development branch. Even if we were going to roll 1.1 today, where would be get it from? I assume TRUNK already contains patches that are meant for 2.x and not 1.x and since backporting to the 1.0.x branch doesn't seem to make sense, what do we do? What am I missing? Brad William A. Rowe, Jr. [EMAIL PROTECTED] Wednesday, December 15, 2004 3:53 PM At 04:31 PM 12/15/2004, Paul Querna wrote: Brad Nicholes wrote: The reason why it's *not* silly is because of our release schedules. Unless the APR project wants to do something completely different with versioning, revision releases (1.0.1 to 1.0.2) are usually on the order of a few months. Point releases (1.0.x to 1.2.x assuming even numbered releases) are usually on the order of years. Major releases (1.x to 2.x) are on the order of who knows when. That has been the history of HTTPD and I don't see any reason why it wouldn't be the history for APR as well. I hope we -don't- try to model httpd. A library such as apr is substantially different than httpd. Given that assumption, I don't want to wait a year for APR 1.2 to be released just to see a minor bug fixed. I want it backported to 1.0.x so that it gets released next month (or sooner). Also using HTTPD as an example, HTTPD 2.2 will not be binary compatible with 2.0. We have already made sure of that with a magic number bump. Therefore, I don't see why APR 1.2.x must be binary compatible with 1.0.x. Because those are our versioning rules... please review them. Although httpd can change it's rules to suit the project, those who adopt the apr library have based their decisions on the rules we had laid down and already voted on. We absolutely cannot break binary compatibility until the next major rev. If that means that apr is 10.1.0 in two years, so be it. I am thinking it might be a good idea todo a 1.1.0 release before httpd-2.2. Or 2.0 - if we actually fix the alignment issues. Lets just do it. Whats stopping a 1.1.0 release today? I don't see any big issues, so, someone needs to take charge as a release manager and make it happen. +1 if 1.1 includes new features, and STATUS showstoppers are closed. hint description=If you have a 1.1 issue, add it to STATUS / Bill
