Project Website | Online Demo | Forum |
It is currently Wed Apr 26, 2017 1:42 pm

All times are UTC + 1 hour [ DST ]





Post new topic Reply to topic  [ 9 posts ] 
  Print view Previous topic | Next topic 

Which pace of versioning?
Poll ended at Wed Oct 31, 2007 1:59 am
Litte features, release very often 0%  0%  [ 0 ]
Quite a few features, release often 0%  0%  [ 0 ]
Lots of features, move complex features 0%  0%  [ 0 ]
Only all possible features are worth a 2.0 tag 0%  0%  [ 0 ]
Total votes : 0
Author Message
 Post subject: Which pace of versioning?
PostPosted: Tue Oct 30, 2007 1:59 am 
Offline
Site Admin
User avatar

Joined: Tue Mar 07, 2006 7:34 pm
Posts: 331
There are several possibilities of versioning future releases of BADGER finance. By "versioning", I think of more than its version number. I include the pace of implementing new features in this term.

Possible options:
  • Implement only little features per version (e. g. only existing features of BADGER 1 in first version of BADGER 2). Release new versions often.
  • Implement quite a few features per version, but keep the principle "release often".
  • Implement lots of features in each version, but move very complex features (taking a lot of time to implement) to future versions.
  • Implement every feature you can think of in version 2.0.


This topic has some dependency on the decision at our modularization strategy

_________________
BADGER finance lead backend developer and site admin


Last edited by enikao on Mon Nov 12, 2007 11:54 pm, edited 1 time in total.

Top
 Profile  
 
 Post subject:
PostPosted: Tue Oct 30, 2007 11:41 am 
Offline
User avatar

Joined: Thu Mar 09, 2006 12:20 am
Posts: 423
Location: Frankfurt a. M., Germany
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.

_________________
cheers,
Holger (project coordinator)


Top
 Profile  
 
 Post subject:
PostPosted: Wed Oct 31, 2007 12:51 am 
Offline
Site Admin
User avatar

Joined: Tue Mar 07, 2006 7:34 pm
Posts: 331
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.

_________________
BADGER finance lead backend developer and site admin


Top
 Profile  
 
 Post subject:
PostPosted: Wed Oct 31, 2007 9:30 am 
Offline
User avatar

Joined: Thu Mar 09, 2006 12:20 am
Posts: 423
Location: Frankfurt a. M., Germany
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.

_________________
cheers,
Holger (project coordinator)


Top
 Profile  
 
 Post subject:
PostPosted: Wed Oct 31, 2007 11:53 am 
Offline
User avatar

Joined: Thu Mar 09, 2006 12:20 am
Posts: 423
Location: Frankfurt a. M., Germany
I dont understand the voting options at all :(

_________________
cheers,
Holger (project coordinator)


Top
 Profile  
 
 Post subject:
PostPosted: Wed Oct 31, 2007 6:47 pm 
Offline
Site Admin
User avatar

Joined: Tue Mar 07, 2006 7:34 pm
Posts: 331
holger wrote:
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).

_________________
BADGER finance lead backend developer and site admin


Top
 Profile  
 
 Post subject:
PostPosted: Wed Oct 31, 2007 6:55 pm 
Offline
User avatar

Joined: Thu Mar 09, 2006 12:20 am
Posts: 423
Location: Frankfurt a. M., Germany
ok understood.

how about this:

- 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.

what do you think ?

_________________
cheers,
Holger (project coordinator)


Top
 Profile  
 
 Post subject:
PostPosted: Wed Oct 31, 2007 7:26 pm 
Offline
Site Admin
User avatar

Joined: Tue Mar 07, 2006 7:34 pm
Posts: 331
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.

_________________
BADGER finance lead backend developer and site admin


Top
 Profile  
 
 Post subject:
PostPosted: Wed Oct 31, 2007 7:33 pm 
Offline
User avatar

Joined: Thu Mar 09, 2006 12:20 am
Posts: 423
Location: Frankfurt a. M., Germany
enikao wrote:
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 knew you would say that ;-)

yes, theoretically agreed. if that really happens, we'll see ...

_________________
cheers,
Holger (project coordinator)


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 9 posts ] 

All times are UTC + 1 hour [ DST ]


Who is online

Users browsing this forum: No registered users and 1 guest


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

Search for:
Jump to:  
cron




Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Style supported by CodeMiles Team.