i think this depends on the result of the "modulization" discussion.
if we decide to take a core vs. module approach, then there would be no common versioning: the core would have a version number and every single module would have its own versioning. this would also ensure that publishing is done at the fastest pace possible, because a ready-to-launch feature module a (e.g. account) would not have to wait for a functionality in module B (statistical analysis) to be done.

In my opinion, even if we do a strict modularization, we need a general BADGER version. For power-users, it's ok to download and integrate improved single modules every few weeks, but regular users will require a more stable approach. A real system test is also to "expensive" to do on every module release, so a thoroughly tested release is required.

i disagree.
if you look at phpbb, they have a core with versioning and each module has its own versioning. works fine. and if the core is done properly, you don't need a thourough system test for each module release, because the modules just *add* to the core and can't harm it.

if you say you still need a general badger version, could you please explain in detail:
- which modules will be included in this general badger
- on basis of what? (who is the developer, how important do we deem the module etc.)
- how would you handle that in the future when new models are being developed?

a middle way would be to define core modules (account grid, user preferences, backup, ... ) and add-on modules (csv parser, statistics, depot, receipts, calendar.
but i see absoutely no point in including a module such as csv parser or statistics in the core and in the core versioning.

i disagree. if you look at phpbb, they have a core with versioning and each module has its own versioning. works fine. and if the core is done properly, you don't need a thourough system test for each module release, because the modules just *add* to the core and can't harm it.

if you say you still need a general badger version, could you please explain in detail:- which modules will be included in this general badger- on basis of what? (who is the developer, how important do we deem the module etc.)- how would you handle that in the future when new models are being developed?

a middle way would be to define core modules (account grid, user preferences, backup, ... ) and add-on modules (csv parser, statistics, depot, receipts, calendar.but i see absoutely no point in including a module such as csv parser or statistics in the core and in the core versioning.

My background is as follows: If somebody googles for "private financial managment" and gets to this page, she does not want to download 17 different packages and read through ten pages of installation instruction, but download one package, extract it, set a database and start using the application. For this, we need a packaged solution.

In theory, this would mean "only" to zip all existing modules. In practice, I would bet there are incompatibilities between some modules, no matter how well-designed the module structure is. And this is _the_ place for capturing such issues.

The comparison to PHPBB is not that good as they have their core functionality in a non-modularized fashion, which seems not to be what we're aiming at (see modules thread).

As for your questions (which modules to include), this is part of the topic of this thread.

Personally, I'm not sure which pace is the best. For the selection of modules to include, I would include as much as possible as long as it's not too big (download-wise) and works properly (which is, again, a test issue).

- suppose badger 2.0 is as modularized as possible. tight core, all functionality in modules
- modules are defined as either "packaged modules" or "extension modules".
- whenever there is a new release of the core, a package is released. this package includes latest version of the core as well as all modules on the "packaged list" in their most recent stable version.
- the very first release would imply that all "packaged modules" have their first stable version.
- all modules may be installed or upgraded individually (packaged modules as well as extension modules)

this way we can release packages and release them as fast as possible (i.e. as fast as the core and not as slow as the slowest module). also, module development can have its own pace and doesnt slow down the whole package or gets slowed down by other modules.

I'm fully ok with this solution, with one addition: If we're doing a good job, the core will become quite stable after a while, so there won't be many new core releases. Therefore, we should also from time to time have new releases with (only) new module versions.

I'm fully ok with this solution, with one addition: If we're doing a good job, the core will become quite stable after a while, so there won't be many new core releases. Therefore, we should also from time to time have new releases with (only) new module versions.

Who is online

Users browsing this forum: No registered users and 1 guest

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum