| View previous topic :: View next topic |
| Author |
Message |
kris
Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific
|
 Posted: Sat Nov 13, 2004 2:06 am Post subject: Mango delivery? |
 |
|
I've been thinking about re-packaging Mango as multiple zip-files and libraries; rather than the single monolithic suite it is today. The packages would probably split along these lines: io, cache, http, log, cluster, icu, and servlet.
The primary goal is to seperate the development stages, and thus make it easier to add new Mango branches without having to completely repackage everything with each individual update. A secondary goal is to allow some of the current packages to hit a release v1.0, without being impeded by others.
What do you think? Any other ideas? |
|
| Back to top |
|
 |
JJR
Joined: 22 Feb 2004
Posts: 1104
|
| Posted: Sat Nov 13, 2004 3:02 am Post subject: |
|
|
I like the idea!
(hope my altogether singular support isn't getting too wearisome)  |
|
| Back to top |
|
|
sean
Joined: 24 Jun 2004
Posts: 609
Location: Bay Area, CA
|
| Posted: Sat Nov 13, 2004 12:36 pm Post subject: |
|
|
| This would be great. I'm a big fan of the modular approach. |
|
| Back to top |
|
|
kris
Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific
|
| Posted: Sat Nov 13, 2004 1:54 pm Post subject: |
|
|
| JJR wrote: | I like the idea!
(hope my altogether singular support isn't getting too wearisome) |
Not at all! What is somewhat wearysome is the historic lack of volunteers (apart from yourself) whenever there's something to do 
C'est la vie! |
|
| Back to top |
|
|
kris
Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific
|
| Posted: Sat Nov 13, 2004 2:00 pm Post subject: |
|
|
| sean wrote: | | This would be great. I'm a big fan of the modular approach. |
Good! Mango was always intended to be a set of sub-projects, but [edit] SVN^H^H^H the forum software couldn't handle it at the time (can it support that now?). This is as good a time as any to change the delivery aspect.
I'll post something later on today ...
Last edited by kris on Sat Nov 13, 2004 8:05 pm; edited 1 time in total |
|
| Back to top |
|
|
brad
Site Admin
Joined: 22 Feb 2004
Posts: 490
Location: Atlanta, GA USA
|
| Posted: Sat Nov 13, 2004 5:02 pm Post subject: |
|
|
How do you want to organize this?
We can have separate projects, forums, and SVN repositories, but that doesn't sound too savory.
SVN can be reorganized to your liking, but still be one big repos. I don't think that SVN is the problem. Maybe you also change the packaging of the downloads...
Forums (actually, multiple forums per project) are an issue, but I'm trying to address that in the next version of dsource. |
|
| Back to top |
|
|
kris
Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific
|
| Posted: Sat Nov 13, 2004 5:48 pm Post subject: |
|
|
| brad wrote: | How do you want to organize this?
We can have separate projects, forums, and SVN repositories, but that doesn't sound too savory.
SVN can be reorganized to your liking, but still be one big repos. I don't think that SVN is the problem. Maybe you also change the packaging of the downloads...
Forums (actually, multiple forums per project) are an issue, but I'm trying to address that in the next version of dsource. |
Forgive my stupidy please Brad ... I actually meant the forum restriction that you mention; not SVN at all ~ just wasn't thinking straight.
Aye, I will change the download packaging. Will probably have a seperate zip file for each sub-project (with both the source and the relevant library). Not sure what to do about the documentation though ~ to get it all cross-referenced properly, doxygen needs to do the whole thing at once. That may be a problem when each package is being released on its own timetable.
Any suggestions for that issue? |
|
| Back to top |
|
|
kris
Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific
|
| Posted: Sat Nov 13, 2004 8:20 pm Post subject: |
|
|
| brad wrote: | | Forums (actually, multiple forums per project) are an issue, but I'm trying to address that in the next version of dsource. |
I'll certainly be one of the first to try that out !
In the meantime, I'll just do something with the download packaging. There's a few niggly problems associated with splitting these packages up ~ the primary one being this: when all the version numbers start diverging, and one package depends upon another (say, http and io), how does one know which version goes with what? Does one just assume that all new packages should be downloaded and installed? If so, then there's little point in maintaining a version number as part of the package, since one should always download all available packages (just to be safe).
Given that, one can then complete the circle by noting it would thus be easier for the user to download a single zipfile; just as it is today
Ideas? |
|
| Back to top |
|
|
brad
Site Admin
Joined: 22 Feb 2004
Posts: 490
Location: Atlanta, GA USA
|
| Posted: Sun Nov 14, 2004 2:33 am Post subject: |
|
|
A tricky problem to be sure, but one that the lead programmer can conrol.
I feel that changes to IO, for example, will be inexorably linked to HTTP, and vice-versa. It will always be there, regardless of the other modules. In fact, certain modules will be so linked that I forsee issues way into the future, with compatibility, galore.
The Apache Foundation should be your model. Tons of sub-libraries/sub-projects that support the main "Tomcat" or "HTTPD". All good stuff, but at the same time, all compatible with the main release (Mango X.x).
BA |
|
| Back to top |
|
|
kris
Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific
|
| Posted: Sun Nov 14, 2004 11:42 am Post subject: |
|
|
| brad wrote: | | The Apache Foundation should be your model |
Agreed; can you summarize how their versioning 'mechanism' operates? |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
