Created on 2009-10-08.00:18:15 by malte, last changed by malte.
|
| msg8892 (view) |
Author: malte |
Date: 2019-06-12.22:59:23 |
|
Removed the summary entries (all dealt with).
This only leaves working on CPLEX-based releases in the future, but there's the
separate issue923 for this.
So we can close this one, in time before its 10-year anniversary. :-)
This makes issue54 is our new Methuselah issue.
|
| msg8797 (view) |
Author: malte |
Date: 2019-06-04.14:39:51 |
|
We should probably explain on the release page what people need to do in order
to get CPLEX working with the release.
|
| msg7145 (view) |
Author: jendrik |
Date: 2018-05-31.21:56:53 |
|
Good idea!
|
| msg7144 (view) |
Author: malte |
Date: 2018-05-31.18:07:40 |
|
Thanks for reviving the discussion! We already have a release target. (See
msg297 and in particular msg454.) How about we make this a priority for the
upcoming sprint?
|
| msg7143 (view) |
Author: jendrik |
Date: 2018-05-31.14:05:23 |
|
In today's Fast Downward meeting we noted that having date-based releases like
"Fast Downward 18.05" might be a good idea (even if we don't release regularly).
Like Ubuntu, we could have point releases like 18.05.1 if we need to make more
than one release in a given month.
|
| msg1322 (view) |
Author: malte |
Date: 2011-04-11.01:12:54 |
|
Once we do this, we should probably also send a (one-time) announcement to
planning-list, with a pointer to the Fast Downward mailing list.
|
| msg694 (view) |
Author: malte |
Date: 2010-11-05.17:26:14 |
|
The licensing bit is now separately handled in issue143.
|
| msg454 (view) |
Author: malte |
Date: 2010-08-12.00:04:11 |
|
> Release target: June 30.
Good thing we didn't specify a year. :-)
|
| msg297 (view) |
Author: malte |
Date: 2010-03-22.14:42:47 |
|
Release target: June 30.
|
| msg30 (view) |
Author: malte |
Date: 2009-10-08.00:18:15 |
|
Once we're done with the cleanup, we should make an official code distribution.
For this, we need:
* a (simple) website where we can put it
* a better/current README
* an update to the "make_dist" script to prepare an appropriate package
* a proper licence (should be included in the package by make_dist)
* some policy on how to deal with the various contributed packages from
Technion and Silvia (like should the thing including everything still be called
"Fast Downward"?)
* some version numbering scheme and a tags directory in the repository
For the licence, we have decided to use the GPL. (Need to find out which version
of it.)
Some of the above points should probably be broken down into separate issues later.
|
|
| Date |
User |
Action |
Args |
| 2019-06-12 22:59:37 | malte | set | status: chatting -> resolved |
| 2019-06-12 22:59:23 | malte | set | messages:
+ msg8892
summary: TODOs:
- license: Read up on the rules for using the GPL and be a bit more rigorous in
following them. For example, they want the license to be shipped with the code.
- document the release process on the wiki (ForDevelopers). Steps include (for a
hypothetical release 19.06):
- create a branch called release-19.06 and a tag called release-19.06.0
- for a later bug fix release, we would create a tag on the release branch
called release-19.06.1
- The trailing ".0" is just an internal thing that we don't make part of
the version, so the official version names are 19.06, 19.06.1, etc.
- Announcement email.
- From the second release onwards: change log based on data from tracker;
example format:
"- issue19 [link]: make official code distribution"
" [some text that comes out of a new change log field in the issue tracker]"
Include the change log in the announcement and also in a CHANGES.md; will
probably require some manual revision until we've got used to what sort of
information to write there.
- release formats: tarball, docker, singularity, vagrant
- to create the tarball, use "hg archive" and use include/exclude; exclude
all dot-files in the main directory (including the auto-generated
.hg_archival.txt, experiments, misc, bitbucket-pipelines.yml)
- should have some way of figuring out what your release is; the lowest-tech
solution is to have to scan the CHANGES.md file. Something more fancy would
be ./fast-downward.py --version.
- create a wiki page for the release; this is also where the tarball and
vagrantfile can live
- things that could be documented in the release email/webpage:
- (sample text, not meant to be copied verbatim) "If you use this version of
Fast Downward in a paper, we encourage you to mention the version number, as in
"We ran experiments with Fast Downward 19.06.""
- "Please use this reference to cite Fast Downward: [journal paper reference]"
- create misc/make-release.sh script (can be named something else)
- try not to overengineer it; we can leave some things non-automated -> |
| 2019-06-05 11:10:34 | augusto | set | nosy:
+ augusto |
| 2019-06-04 14:39:51 | malte | set | messages:
+ msg8797 |
| 2019-06-04 14:36:20 | malte | set | status: deferred -> chatting
summary: TODOs:
- license: Read up on the rules for using the GPL and be a bit more rigorous in
following them. For example, they want the license to be shipped with the code.
- document the release process on the wiki (ForDevelopers). Steps include (for a
hypothetical release 19.06):
- create a branch called release-19.06 and a tag called release-19.06.0
- for a later bug fix release, we would create a tag on the release branch
called release-19.06.1
- The trailing ".0" is just an internal thing that we don't make part of
the version, so the official version names are 19.06, 19.06.1, etc.
- Announcement email.
- From the second release onwards: change log based on data from tracker;
example format:
"- issue19 [link]: make official code distribution"
" [some text that comes out of a new change log field in the issue tracker]"
Include the change log in the announcement and also in a CHANGES.md; will
probably require some manual revision until we've got used to what sort of
information to write there.
- release formats: tarball, docker, singularity, vagrant
- to create the tarball, use "hg archive" and use include/exclude; exclude
all dot-files in the main directory (including the auto-generated
.hg_archival.txt, experiments, misc, bitbucket-pipelines.yml)
- should have some way of figuring out what your release is; the lowest-tech
solution is to have to scan the CHANGES.md file. Something more fancy would
be ./fast-downward.py --version.
- create a wiki page for the release; this is also where the tarball and
vagrantfile can live
- things that could be documented in the release email/webpage:
- (sample text, not meant to be copied verbatim) "If you use this version of
Fast Downward in a paper, we encourage you to mention the version number, as in
"We ran experiments with Fast Downward 19.06.""
- "Please use this reference to cite Fast Downward: [journal paper reference]"
- create misc/make-release.sh script (can be named something else)
- try not to overengineer it; we can leave some things non-automated |
| 2018-06-04 08:15:00 | cedric | set | nosy:
+ cedric |
| 2018-06-01 13:44:42 | silvan | set | nosy:
+ silvan |
| 2018-06-01 11:42:12 | florian | set | nosy:
+ florian |
| 2018-06-01 06:42:03 | thomas | set | nosy:
+ thomas |
| 2018-05-31 21:56:53 | jendrik | set | messages:
+ msg7145 |
| 2018-05-31 18:10:14 | guillem | set | nosy:
+ guillem |
| 2018-05-31 18:07:40 | malte | set | messages:
+ msg7144 |
| 2018-05-31 14:05:23 | jendrik | set | nosy:
+ jendrik
messages:
+ msg7143 |
| 2011-04-11 01:12:54 | malte | set | messages:
+ msg1322 |
| 2010-11-05 17:26:14 | malte | set | messages:
+ msg694 |
| 2010-08-12 00:04:11 | malte | set | messages:
+ msg454 |
| 2010-03-22 14:42:47 | malte | set | nosy:
+ erez, gabi, silvia
messages:
+ msg297 |
| 2010-03-22 14:30:29 | malte | set | keyword:
+ 1.0 |
| 2009-10-08 00:18:15 | malte | create | |
|