Menu
▾
▴
opendocumentphp-developers
|
From: Andreas N. <ane...@az...> - 2007-02-12 08:54:35
|
> >0.7.0 (codename 'Dortmund') > The main goal of Dortmund are the spreadsheets. > We should focus mainly on the OpenDocumentSpreadsheet class and the > table/tablecell stuff. So you can count me in if you are arriving at "Dortmund". My suggestion for the next Codename is "Brochterbeck". c u Andreas 'Nupela Didiman' Neugebauer ---------- EDV - Leiter Tel: +49 421 59 08 166 Azul Kaffee GmbH & Co. KG Fax: +49 421 59 08 108 Am Deich 43 Mobil:+49 177 38 85 486 D - 28199 Bremen SKYPE: aneugebauer ---------- B=FCro: ane...@az... Privat: and...@ew... ---------- Quam quisque norit artem, in hac se exerceat ! AZUL KAFFEE GmbH & Co. KG Am Deich 43 D-28199 Bremen Tel.: +49 (0)421 59 08 0 Fax: +49 (0)421 59 08 200 Mail: in...@az... http://www.azul.de ---------------------------------------------------------------------------------------------------- Kommanditgesellschaft, AG Bremen HRA 14059 pers=F6nlich haftender Gesellschafter: W.Wille AZUL KAFFEE GmbH Bremen AG Bremen HRB 4324 Gesch=E4ftsf=FChrer: Dr. Helmut Reining USt.-Identnummer: DE 114 617 193 Steuernummer: 73 505 22306 / =D6sterreich 993/7027 |
|
From: <no...@se...> - 2007-02-15 08:13:58
|
Hi Alex, hi all other developers, > Hmm, I am not convinced by the whole build/ directory, do we really need > to keep all the old version in the repository? Shouldn't it just be the > current version as we are using a subversion system, thus keeping all > previous versions? This makes the most sense to me, apart from that > though I like it a lot. the idea was that you _can_ keep all the old releases. With a 'phing proper' (or so) you will be able to remove _all_ the stuff in the build directroy, if you want. (By 'phing clean' only the current build part should be deleted.) But if you want to keep the old stuff, you will be able to do this in a, as I think, clever and clearly arranged way with this structure. Be aware, everything inside build/ is build on your system and is part of the cleaning or proper cleaning task. All the other subdirectories are part of the repository. > PS.. Good Job on the website Norman :) Thanks, first time that I use this Joomla! cms. But it was easy to customize it this way. But it is far away from being prefect or even ready. ;-) (For all others: take a look at http://opendocumentphp.org/index.php - I am still working on the css, but if somebody want's to take over ....) Yours, Norman |
|
From: Daniel L. <dlo...@gm...> - 2007-02-16 05:06:21
|
Norman: What would be a suitable place to break myself into the project? I understand the overarching purpose of OpenDocument and what we specifically are trying to accomplish but I lack experience in development of this nature. I am looking forward to contributing (and learning along the way), but I don't know the best place to begin Regards, Dan On 2/15/07, no...@se... <no...@se...> wrote: > > Hi Alex, hi all other developers, > > > Hmm, I am not convinced by the whole build/ directory, do we really need > > to keep all the old version in the repository? Shouldn't it just be the > > current version as we are using a subversion system, thus keeping all > > previous versions? This makes the most sense to me, apart from that > > though I like it a lot. > > the idea was that you _can_ keep all the old releases. With a 'phing > proper' (or so) you will be able to remove _all_ the stuff in the build > directroy, if you want. (By 'phing clean' only the current build part > should be deleted.) But if you want to keep the old stuff, you will be > able to do this in a, as I think, clever and clearly arranged way with > this structure. Be aware, everything inside build/ is build on your system > and is part of the cleaning or proper cleaning task. All the other > subdirectories are part of the repository. > > > PS.. Good Job on the website Norman :) > > Thanks, first time that I use this Joomla! cms. But it was easy to > customize it this way. But it is far away from being prefect or even > ready. ;-) > > (For all others: take a look at http://opendocumentphp.org/index.php - I > am still working on the css, but if somebody want's to take over ....) > > > Yours, > Norman > > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > OpenDocumentPHP-Developers mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opendocumentphp-developers > |
|
From: <no...@se...> - 2007-02-16 13:25:03
|
Dear Dan, and hi to all other developers too, Daniel Longest wrote: > Norman: > What would be a suitable place to break myself into the project? I understand the overarching purpose of OpenDocument and what we specifically are trying to accomplish but I lack experience in development of this nature. I am looking forward to contributing (and learning along the way), but I don't know the best place to begin > > Regards, > Dan your question about suitable places to break into the project is not so easy to be answered. Let me see what we need: - some examples, a webpage, for instance, where you could write some lines. Fill in some meta data forms and we make a odt out of it. - the manifest class has some missing functionality, which should be 'easiely' added by some one... - an extension to add thumbnails (or something like thumbnails) to the od-archive would be nice, but seems not so important. - currently we are working on the text (and more or less on the spreadsheet) part of a OpenDocument. The *:number format stuff is needed by both parts in a way. This could be a good staring point for some new classes. - the possibility to add math formula (as text or as chart formula) is another good point to start. Maybe something with MathML... - Last but not least: Refaktoring! Refaktoring! Refaktoring! I hope I could help a little. More about this next week. Yours, Norman BTW: Currently only Alex, Andreas and me do have write access to the svn! Are there any others who wants to join us? |
|
From: Daniel L. <dlo...@gm...> - 2007-02-20 04:32:56
|
Norman et al: Sorry for the several day delay on my response. > - some examples, a webpage, for instance, where you could write some > lines. Fill in some meta data forms and we make a odt out of it. This one, at least on its face, appears to be the "easiest" for a new developer to the project. If I am understanding you/the project correctly, I would need to basically provide the functionality to convert a basic web page with form to an ODT. Is that correct? > - the manifest class has some missing functionality, which should be > 'easiely' added by some one... Forgive my ignorance and I apologize if this is answered in the project docs, but I'm currently unfamiliar with the manifest. > - currently we are working on the text (and more or less on the > spreadsheet) part of a OpenDocument. The *:number format stuff is needed > by both parts in a way. This could be a good staring point for some new > classes. If I understand this part correctly, you are talking about the actual grunt labor of converting a text file to OpenDoc, specifically dealing numeric formatting (which can be shared across multiple parts for such formatting as needed). I am leaning towards working on the first task that I quoted, translating meta data webpage forms into ODT, assuming I understood the objective. What is the "best" way to test my code? I guess a way to rephrase that question is: where can I (or should I be using) a standalone PHP interpreter? Or is the "best" way simply through a locally installed Apache webserver configured with PHP? I realize some of these questions are rather simple but I want to make absolutely certain I understand the basics before wreaking havoc :-) Regards, Dan On 2/16/07, no...@se... <no...@se...> wrote: > > Dear Dan, and hi to all other developers too, > > Daniel Longest wrote: > > > Norman: > > What would be a suitable place to break myself into the project? I > understand the overarching purpose of OpenDocument and what we > specifically are trying to accomplish but I lack experience in > development of this nature. I am looking forward to contributing (and > learning along the way), but I don't know the best place to begin > > > > Regards, > > Dan > > your question about suitable places to break into the project is not so > easy to be answered. Let me see what we need: > > > - the possibility to add math formula (as text or as chart formula) is > another good point to start. Maybe something with MathML... > > - Last but not least: Refaktoring! Refaktoring! Refaktoring! > > I hope I could help a little. More about this next week. > > Yours, > > Norman > > BTW: Currently only Alex, Andreas and me do have write access to the svn! > Are there any others who wants to join us? > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > OpenDocumentPHP-Developers mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opendocumentphp-developers > |
|
From: <no...@se...> - 2007-02-20 13:18:21
|
Hi Dan et. al, Daniel Longest wrote: > Norman et al: > Sorry for the several day delay on my response. we are all doing this as a hobby in our spare time, not as a job, so you don't need to apologize for any delay. > > - some examples, a webpage, for instance, where you could write some > > lines. Fill in some meta data forms and we make a odt out of it. > > This one, at least on its face, appears to be the "easiest" for a new developer to the project. If I am understanding you/the project correctly, I would need to basically provide the functionality to convert a basic web page with form to an ODT. Is that correct? Okay, I will concrete my thoughts a little bit more: I would like to see a webpage with a (or some) forms, where you can input some (plain) paragraphs and some meta data (like the file name, the creation date, the initial creator ... what ever you find interesting in the DublinCoreFragment and MetaFragment classes in the src/meta directory) and then press a button and you can download a freshly made OpenDocumentText. This webpage should also be on our website (http://opendocumentphp.org) as a short demo. A good start should be to take a look at the src/samples/OpenDocumentTextTest.php file and get rid of the "test" stuff. You should easily get the code you need to create a OpenDocumentText. The missing part is the website stuff. (Please you a production code statement at the beginning, like require_once 'OpenDocumentPHP/...' and not the one in the test file require_once '...'!) > > - the manifest class has some missing functionality, which should be > > 'easiely' added by some one... > > Forgive my ignorance and I apologize if this is answered in the project docs, but I'm currently unfamiliar with the manifest. Okay, the manifest is the basic directory of an OpenDocument package. Every file you put in the OpenDocument package is listed in two places. The first place is in the zip file directory, this is done automatically by the ZIP class. The second place is in a special file, called the manifest. This is very similar to the MANIFEST.MF you will find in every (good) JAR file. Sun has decided to spend OpenDocument also a manifest, but one in XML style. So every OpenDocument packages has a manifest.xml in witch you can find all the files in the OpenDocument package with some extra data. Currently we support only the main parts of this manifest. But you can also add some more data. More informations about this are in the OpenDocument specifications. > > - currently we are working on the text (and more or less on the > > spreadsheet) part of a OpenDocument. The *:number format stuff is needed > > by both parts in a way. This could be a good staring point for some new > > classes. > > If I understand this part correctly, you are talking about the actual grunt labor of converting a text file to OpenDoc, specifically dealing numeric formatting (which can be shared across multiple parts for such formatting as needed). I will give response to that part later, okay? > I am leaning towards working on the first task that I quoted, translating meta data webpage forms into ODT, assuming I understood the objective. What is the "best" way to test my code? I guess a way to rephrase that question is: where can I (or should I be using) a standalone PHP interpreter? Or is the "best" way simply through a locally installed Apache webserver configured with PHP? The best thing for the first subproject is to start with a local Apache webserver, I think (WAMP or XAMP or ... ???). You should check that you have PHP 5.2.0 or 5.2.1 running on the server. After that, install the current _production code_ and write some code that will run under Apache in PHP (or was in in Apache under PHP???). If you got it, tell us and we will include this in the source tree. > I realize some of these questions are rather simple but I want to make absolutely certain I understand the basics before wreaking havoc :-) No problem, mostly my faults. I know, I should talk more about what I am thinking on this list (or in my blog) and I promise to do so.... Yours, Norman |
|
From: Daniel L. <dlo...@gm...> - 2007-02-21 05:30:16
|
Team:
I spent a few hours today (while at work, luckily it was a slow day)
reviewing a number of things, including the most recent version of the
source code and the OASIS ODF specification to get a better handle on
everything. While complex initially, it is already making a great deal of
sense. In addition, Norman, your email comments helped a lot in clarifying
the issues and questions in my mind. I have thus begun work toward the task
I mentioned I would attempt: a basic webpage to create an ODT file on the
fly. I did not understand one thing you said, the line
" (Please you a production code statement
at the beginning, like require_once 'OpenDocumentPHP/...' and not the one
in the test file require_once '...'!)"
You are clearly referring to include statements for classes in the project.
My lack of familiarity with the project or perhaps some newness to PHP leads
to a very basic question: what should I put? I am leaning towards thinking
that the format you want is an absolute path
require_once statement to the root of the OpenDocument code. In other words,
when I proceed to use the OpenDocumentText class, are you saying I should
do:
require_once('OpenDocumentPHP/OpenDocument.php');
and I were to use DublinCoreFragment, I should do
require_once('OpenDocumentPHP/meta/DublinCoreFragment.php');
If I have totally misunderstood, please show me (it will only take once) and
I will do right from now on.
I should say, before we get too far into this, that I will take any and all
criticism of my coding style or logic. I have programmed for a long time but
have little formal training in matters such as version release and team
programming. I am always open to suggestions and refinements to better
improve my skills and our project and will not take what you say personally.
(obviously you mentioned refactoring as a project-wide series of a constant
refinements).
To wrap up, my sourceforge username is dlongest (should be easy to remember
:-) I hope to have something (useable is the wrong word) demonstrative by
the end of the week to be examined, prodded, and inspected as my first
project submission. I am using xampp to run Apache and PHP locally for my
test client. Are we running production code with superglobals turned on or
off? I want to make my local environment as close to the production
environment as possible. If these questions are answered in another already
written resource, please direct me to it and I will answer as much as I can
for myself.
Regards,
Dan
On 2/20/07, no...@se... <no...@se...> wrote:
>
> Hi Dan et. al,
>
>
> Daniel Longest wrote:
> > Norman et al:
> > Sorry for the several day delay on my response.
> we are all doing this as a hobby in our spare time, not as a job, so you
> don't need to apologize for any delay.
> > > - some examples, a webpage, for instance, where you could write some
> > > lines. Fill in some meta data forms and we make a odt out of it.
> >
> > This one, at least on its face, appears to be the "easiest" for a new
> developer to the project. If I am understanding you/the project
> correctly, I would need to basically provide the functionality to
> convert a basic web page with form to an ODT. Is that correct?
>
> Okay, I will concrete my thoughts a little bit more:
>
> I would like to see a webpage with a (or some) forms, where you can input
> some (plain) paragraphs and some meta data (like the file name, the
> creation date, the initial creator ... what ever you find interesting in
> the DublinCoreFragment and MetaFragment classes in the src/meta directory)
> and then press a button and you can download a freshly made
> OpenDocumentText. This webpage should also be on our website
> (http://opendocumentphp.org) as a short demo.
> A good start should be to take a look at the
> src/samples/OpenDocumentTextTest.php file and get rid of the "test" stuff.
> You should easily get the code you need to create a OpenDocumentText. The
> missing part is the website stuff. (Please you a production code statement
> at the beginning, like require_once 'OpenDocumentPHP/...' and not the one
> in the test file require_once '...'!)
> > > - the manifest class has some missing functionality, which should be
> > > 'easiely' added by some one...
> >
> > Forgive my ignorance and I apologize if this is answered in the project
> docs, but I'm currently unfamiliar with the manifest.
> Okay, the manifest is the basic directory of an OpenDocument package.
> Every file you put in the OpenDocument package is listed in two places.
> The first place is in the zip file directory, this is done automatically
> by the ZIP class. The second place is in a special file, called the
> manifest. This is very similar to the MANIFEST.MF you will find in every
> (good) JAR file. Sun has decided to spend OpenDocument also a manifest,
> but one in XML style. So every OpenDocument packages has a manifest.xml in
> witch you can find all the files in the OpenDocument package with some
> extra data.
> Currently we support only the main parts of this manifest. But you can
> also add some more data. More informations about this are in the
> OpenDocument specifications.
>
> > > - currently we are working on the text (and more or less on the
> > > spreadsheet) part of a OpenDocument. The *:number format stuff is
> needed
> > > by both parts in a way. This could be a good staring point for some
> new
> > > classes.
> >
> > If I understand this part correctly, you are talking about the actual
> grunt labor of converting a text file to OpenDoc, specifically dealing
> numeric formatting (which can be shared across multiple parts for such
> formatting as needed).
> I will give response to that part later, okay?
>
> > I am leaning towards working on the first task that I quoted,
> translating meta data webpage forms into ODT, assuming I understood the
> objective. What is the "best" way to test my code? I guess a way to
> rephrase that question is: where can I (or should I be using) a
> standalone PHP interpreter? Or is the "best" way simply through a
> locally installed Apache webserver configured with PHP?
> The best thing for the first subproject is to start with a local Apache
> webserver, I think (WAMP or XAMP or ... ???). You should check that you
> have PHP 5.2.0 or 5.2.1 running on the server. After that, install the
> current _production code_ and write some code that will run under Apache
> in PHP (or was in in Apache under PHP???). If you got it, tell us and we
> will include this in the source tree.
>
> > I realize some of these questions are rather simple but I want to make
> absolutely certain I understand the basics before wreaking havoc :-)
>
> No problem, mostly my faults.
>
> I know, I should talk more about what I am thinking on this list (or in my
> blog) and I promise to do so....
>
> Yours,
> Norman
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> OpenDocumentPHP-Developers mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opendocumentphp-developers
>
|
|
From: <no...@se...> - 2007-02-21 08:41:10
|
Hi Dan et al, the problem is the current directory structure. The source code is in the src/ directory and all source code references are made with a base directory './src' in mind. The problem is now, that if you run OpenDocumentPHP as a library you will have your own program as code base and the OpenDocumentPHP stuff in your classpath. So you have the separate your own source code from the OpenDocumentPHP source code. For instance, you will include the PEAR stuff always with something like 'require_once "Phing/PhingFile.php";' or 'require_once "PHPUnit/PHPUnit_TestSuite.php";'. If you take a look at the published files on sourceforge.net you will find two packages. One is call OpenDocumentPHP-0.5.1-src.zip, which is a more or less a snapshot of the subvision repository at a certain time. But there is also a file named OpenDocumentPHP-0.5.1.zip, which is what we call the 'production code'. It is only the library (and the api documentation done by PhpDocumentor) and that is what people need, if they only what to use our code. If you take a look at that part of the code you will see, that there is a directory OpenDocumentPHP which includes all our production code and that all the line like "require_once 'meta/DublinCoreFragment.php';" are substituted by something like "require_once 'OpenDocumentPHP/meta/DublinCoreFragement.php';". The new directroy structure will end this messy situation, by putting all the code in src/OpenDocumentPHP/ which should go as OpenDocumentPHP/ in the library and all other code (like the samples, tools etc) in the src/samples/, src/tools/ ... directories. So if you develop an example for OpenDocumentPHP you should use the production or new directory structure to include the classes, thinking that OpenDocumentPHP was lnked by the user in there classpath. May be I should write a simple sample first. ;-) So, Dan, your are complete right, when you want to use > require_once('OpenDocumentPHP/OpenDocument.php'); and > require_once('OpenDocumentPHP/meta/DublinCoreFragment.php'); because you added OpenDocumentPHP first, even when there is (currently) no such suffix in the require_once statements in the source code. > I should say, before we get too far into this, that I will take any and all criticism of my coding style or logic. I have programmed for a long time but have little formal training in matters such as version release and team programming. I am always open to suggestions and refinements to better improve my skills and our project and will not take what you say personally. (obviously you mentioned refactoring as a project-wide series of a constant refinements). As you can (not ?) see, I love such things as "Agile Development" or "XP". The problem is, that I spend most of the time in coding then follow the rules of XP or AD, shame on me! But if you use a project not only to finish something, but to learn more and get benefit not you by getting it done but also by see how your own vision changes ... well too much dreaming I think... > To wrap up, my sourceforge username is dlongest (should be easy to remember :-) I hope to have something (useable is the wrong word) demonstrative by the end of the week to be examined, prodded, and inspected as my first project submission. I am using xampp to run Apache and PHP locally for my test client. That would be nice. > Are we running production code with superglobals turned on or off? No superglobals please. Always thing of a hyper secure system, that allows nearly nothing! ;) Yours, Norman PS: Dan, you have now SVN access, too. |
|
From: <no...@se...> - 2007-02-21 13:31:07
|
Hi folks, I ame desperately waiting for the next Phing release (2.3.0 or 2.2.1 what ever published next). Until than you have to patch the old 2.2.0 release to work together with the current PHPUnit 3.0.X release or try the SVN release which makes you need a new build.xml file. I my local development environment I currently use the SVN build of Phing with a new build.xml and trying to setup the new phase1nt directory structure. This realy is a major step forward, but without a shipped Phing 2.3.0 it is to hard to maintain both (a release working with 2.2.0 and one with 2.3.0/svn). So I will put on this as soon as Phing 2.3.0 is published. If you have setup a running Phing direct from the SVN, you can ask me by private mail to get a copy from phase1nt tree. Yours, Norman Markgraf |
|
From: <no...@se...> - 2007-02-13 12:17:48
|
Hi folks, currently I try to set up a new release 0.5.1 as soon as possible, because I found a lot of nasty little bugs (mostly missing request_once statements) in the 0.5.0 release. Well I guess that made it a real .0 release. I send some money and get the domain name opendocumentphp.org. So any active developer can get a project specific email adress like: no...@op... or al...@op... which will be virues and spamm checked and after that forwarded to your normal email adress, if you want, or stored as POP3 or IMAP on the server (with email quotas!). If you are interessed, drop me a line. I hope the server will get online end of this week. I think our file and directory structure needs an update. I will publish me thoughts later, but in advance: currenty we have a src/ directory with all the sources. I like the idea of inserting four subdirectories: OpenDocumentPHP/ - Which will get the current source code test/ - Here we will put our PHPUnit test code samples/ - Here we can put our sample code tools/ - Here we can put our tools (yes, I will need it!) But also other parts needs some tailoring. @Andreas: There is currently a not so well developed spreadsheet class in the source, feel free to look at it an tell me what you need ;-) We can change our goals if needed ;-) Yours Norman |
|
From: <no...@se...> - 2007-02-14 13:35:49
|
Dear developers, today I will present you my thoughts about a new directory structure for our code base. The current situation is as follows: /phase1/ src/ etc/ Schemata/ PhingStyles/ doc/ build/ build.xml build.properties LICENSE README I would like to change that to something like this: /phase1/ etc/ Schemata/ PhingStyles/ doc/ TEAM ROADMAP CHANGELOG build/ 0.5.0/ apidoc/ reports/ code-coverage/ unittests/ OpenDocumentPHP-0.5.0.zip OpenDocumentPHP-0.5.0-source.zip 0.5.1/ apidoc/ reports/ code-coverage/ unittests/ OpenDocumentPHP-0.5.1.zip OpenDocumentPHP-0.5.1-source.zip .../ src/ OpenDocumentPHP/ unittests/ samples/ tools/ build.xml build.properties LICENSE README What do you think about this? Regards, Norman |
|
From: Alex L. <ad...@ya...> - 2007-02-14 22:07:27
|
no...@se... wrote: > Dear developers, > > today I will present you my thoughts about a new directory structure for > our code base. The current situation is as follows: > > /phase1/ > src/ > etc/ > Schemata/ > PhingStyles/ > doc/ > build/ > build.xml > build.properties > LICENSE > README > > I would like to change that to something like this: > > /phase1/ > etc/ > Schemata/ > PhingStyles/ > doc/ > TEAM > ROADMAP > CHANGELOG > build/ > 0.5.0/ > apidoc/ > reports/ > code-coverage/ > unittests/ > OpenDocumentPHP-0.5.0.zip > OpenDocumentPHP-0.5.0-source.zip > 0.5.1/ > apidoc/ > reports/ > code-coverage/ > unittests/ > OpenDocumentPHP-0.5.1.zip > OpenDocumentPHP-0.5.1-source.zip > .../ > src/ > OpenDocumentPHP/ > unittests/ > samples/ > tools/ > build.xml > build.properties > LICENSE > README > > What do you think about this? > > Regards, > > Norman > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > OpenDocumentPHP-Developers mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opendocumentphp-developers > > Hmm, I am not convinced by the whole build/ directory, do we really need to keep all the old version in the repository? Shouldn't it just be the current version as we are using a subversion system, thus keeping all previous versions? This makes the most sense to me, apart from that though I like it a lot. Thanks Alex. PS.. Good Job on the website Norman :) |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X