History of PackagerPackage

{maketoc}
! Package
Please enter the name of the package you are uploading. You can use whatever name you like, but please bear in mind that the name will be converted to lower case and that any special characters will be removed.

! Version
Versioning in bitweaver follows some basic rules. The version numbers are split into 3 distinct parts __major.minor.trivial.status__ where every segment has it's own purpose. Here is a brief description of how version numbers are assigned to the core packages in bitweaver:
;major:This is used for stable releases and for core packages it means that there have been changes to the database. if you are developing packages, you can rely on bitweaver core packages using a consistent set of tables within each major release.
;minor:This usually denotes some API changes and other large changes that could potentially influence the way your package interacts with the core.
;trivial:Usually these are minor bugfixes and should have no influence on the interaction of external packages on the core.
;status:The status of the package signifies it's development status. There are a few options to choose from and the ranking is as follows: dev < alpha < beta < pl. This will indivate to the user what state the package is in and can then decide if they want to download and install the given package.
Due to the interrelated nature of the core packages, these can only be upgraded all at once and will always have the same version number accross the board.

Version is set in your admin/schema_inc.php file:
{code title="Setting the Package Version"}
$gBitInstaller->registerPackageVersion( WIKI_PKG_NAME, '0.0.1.pl' );
{/code}

!! Core packages
Core packages are required packages in bitweaver. These packages are considered core and bitweaver will not work without these:
* kernel
* liberty
* languages
* themes
* users
* util
* install
* storage
* temp

! Package Type
Package creation in bitweaver is quite simple and therefore there are many different packages that are available. Grouping packages into their types makes it easy for other users to find a package of a given type

! Package description
This should contain a brief summary of your package, what it does and what if provides. You can provide extensive documentation elsewhere and provide a link to that place using the Documentation URL enty field.

! Documentaion URL
If you have set up a website with more information about this package, please provide it here.

! Upload Package
Chose the package archive you wish to upload. The name of the file is irrelevant since it will be renamed using the information provided above. The final filename will be:
<package name>-<version>-<status>.tar.gz

the archives you upload will be extracted and checked for a few required parameters. Firstly, the package needs to be contained in a folder within the archive. For packages to work in bitweaver, the bit_setup_inc.php file is required and will therefore be searched for. If this file does not exist, the package is considered non-functional and will be discarded.

! Author
Enter the name of the author or provide a valid email address.

! Maintainer URL
This can be a url to a website where more information about the package is provided.

! License
Pick a license appropriate for your package.

! Security Release
Only check this box if the release is a security release. This will highlight the package in the package manager and alert the user that there are important upgrades available.

! Service
Only check this box if the package you are providing is a true service to other packages such as categorisation.

! Requirements
Here you can enter the requirements or your package. to specify a requirement of a certain version of the core packages, please use __kernel__ for this.
{code title="Requirements format"}
kernel 2.0.1 2.1.1
wiki 0.2.1.pl 0.3.0
{/code}
this will indicate that the package being uploaded works with kernel from version 2.0.1 to version 2.1.1 and with wiki of versions between 0.2.1.pl and 0.3.0.

! Changelog
The changelog should be provided as a textfile which will be interpreted after the upload. Every line should contain one entry. Lines that don't start with +, - or ! will be ignored. If you keep a log file spanning multiple versions, please separate versions using [<version>.<status>] as set in the [#Version|version] section.
* Date is not required but recommended. If you insert the date, please use the [http://www.w3.org/QA/Tips/iso-date|IS0 8601] date format: __YYYY-MM-DD__
* One entry per line.
{code title="Changelog format"}
[1.3.6.release]
+ 2007-04-28 This is a new feature
- 2007-04-27 This feature was removed
! 2007-04-26 This bug was squished

[1.3.4.beta]
+ 2007-04-24 This is a new feature
- 2007-04-23 This feature was removed
! 2007-04-22 This bug was squished
{/code}

! Plans
on creation of package details, we link to or create wiki page with <package>Package title and ask author to provide some information there
create service that we can display packager_details in wiki specific wiki page as set by bwo_content_id

! Developers
Here are a few points to keep in mind when creating an upgrade file:
* Order in which the upgrades are listed is not important
* Upgrade key must use a valid version number and status - all others will be ignored
* Only upgrades since the last install until the current release will be included

Using the code below, and upgrading from 0.0.0 to 0.0.4 the upgrade process would include in this order:
* 0.0.2.dev
* 0.0.2.alpha
* 0.0.2
* 0.0.2.pl
* 0.0.3
Please note that 0.0.2.glue will be ignored entirely. only upgrades with valid version numbers will be included.

{code title="Valid upgrade file setup"}
<?php
$schemaUpgrades['0.0.6'] = array(
array('QUERY' =>
array( 'SQL92' => array(
"INSERT INTO `".BIT_DB_PREFIX."kernel_config` (`config_name`,`config_value`, `package`)
VALUES ('version.0.0.6', 'testing the upgrade process', 'packager')",
),
)),
);

$schemaUpgrades['0.0.0'] = array(
array('QUERY' =>
array( 'SQL92' => array(
"INSERT INTO `".BIT_DB_PREFIX."kernel_config` (`config_name`,`config_value`, `package`)
VALUES ('version.0.0.0', 'testing the upgrade process', 'packager')",
),
)),
);

$schemaUpgrades['0.0.2'] = array(
array('QUERY' =>
array( 'SQL92' => array(
"INSERT INTO `".BIT_DB_PREFIX."kernel_config` (`config_name`,`config_value`, `package`)
VALUES ('version.0.0.2', 'testing the upgrade process', 'packager')",
),
)),
);

$schemaUpgrades['0.0.2.alpha'] = array(
array('QUERY' =>
array( 'SQL92' => array(
"INSERT INTO `".BIT_DB_PREFIX."kernel_config` (`config_name`,`config_value`, `package`)
VALUES ('version.0.0.2.alpha', 'testing the upgrade process', 'packager')",
),
)),
);

$schemaUpgrades['0.0.2.glue'] = array(
array('QUERY' =>
array( 'SQL92' => array(
"INSERT INTO `".BIT_DB_PREFIX."kernel_config` (`config_name`,`config_value`, `package`)
VALUES ('version.0.0.2.pl', 'testing the upgrade process', 'packager')",
),
)),
);

$schemaUpgrades['0.0.2.pl'] = array(
array('QUERY' =>
array( 'SQL92' => array(
"INSERT INTO `".BIT_DB_PREFIX."kernel_config` (`config_name`,`config_value`, `package`)
VALUES ('version.0.0.2.pl', 'testing the upgrade process', 'packager')",
),
)),
);

$schemaUpgrades['0.0.2.dev'] = array(
array('QUERY' =>
array( 'SQL92' => array(
"INSERT INTO `".BIT_DB_PREFIX."kernel_config` (`config_name`,`config_value`, `package`)
VALUES ('version.0.0.2.dev', 'testing the upgrade process', 'packager')",
),
)),
);

$schemaUpgrades['0.0.3'] = array(
array('QUERY' =>
array( 'SQL92' => array(
"INSERT INTO `".BIT_DB_PREFIX."kernel_config` (`config_name`,`config_value`, `package`)
VALUES ('version.0.0.3', 'testing the upgrade process', 'packager')",
),
)),
);
?>
{/code}
Page History
Date/CommentUserIPVersion
24 Apr 2007 (06:53 UTC)
xing194.152.164.453
Current • Source
xing194.152.164.452
View • Compare • Difference • Source
xing194.152.164.451
View • Compare • Difference • Source