Support #1711
Development releases?
Description
Ulrich suggested that we make "development releases" frequently available.
Advantages include that others can work with the latest "development" version (rather than the last official release, which could be several months old).
A possibility would be to make the CVS copy more widely readable; or we could run a script to make weekly (or daily?) snapshots which are placed on the website.
History
#1
Updated by John Abbott over 1 year ago
Updated by JAA can see the advantage: Ulrich had kindly made several patches to the last "official release" from about 6 months ago.
Not surprisingly I had considerable difficulty applying his patches to the latest internal version which I had.
We would have to make clear that it is only for developers (and so many be impressively buggy).
Another advantage is that we could get swift feedback from volunteer testers who like to "play" with the code.
This should help guarantee better portability, and generally wider testing.
Personally, I am reticent about allowing wider access to CVS -- probably unfounded fears about data-security(?)
Given the rate at which we update the code, I would think that weekly snapshots could be a good solution.
#2
Updated by John Abbott over 1 year ago
- Status changed from New to In Progress
- % Done changed from 0 to 10
Questions:
(1) how burdensome would it be to make weekly snapshots available on the website?
[ how would we do this? Make a special page? ]
(2) How unsafe would it be to allow read-only access to CVS?
Is this technically feasible? What are the risks?
What does the "tecnico" say?
#3
Updated by John Abbott over 1 year ago
Anna says that (1) requires manually copying the file to the server running the website.
She'll probably try doing it for a while, and see how tedious it is...
Read access to CVS is unlikely to be approved.
#4
Updated by John Abbott over 1 year ago
- % Done changed from 10 to 20
JAA thinks making "snapshot" TGZ releases is probably a good idea.
It really helps those volunteers who would like to contribute to
the project... and also us when we receive contributions (it can be
a pain merging when the contributions refer to an old version).
We must make clear that "snapshots" are just for developers.
#5
Updated by John Abbott over 1 year ago
- % Done changed from 20 to 30
- Anna will make a new web page (with clearly written that snapshots are just for testing, no guarantees, etc);
- the snapshot webpage will be accessible from CoCoA website main page (at least eventually)
- the download filename will be constant e.g.
CoCoALib-snapshot.tgz - inside the TGZ will be a directory with name something like
CoCoALib-0.99810-20221130-182736/(the long name should help identify exactly which version is being used) - presumably snapshots will only be GPLv3+
- older snapshots will not be retained (at least not accessible to public)
- snapshots will be made only semi-regularly (e.g. every 1-2 weeks)
No decision about when to make the first trial -- hopefully soon!
#6
Updated by Anna Maria Bigatti over 1 year ago
Updated by - Assignee set to Anna Maria Bigatti
#7
Updated by John Abbott over 1 year ago
- Status changed from In Progress to Resolved
- % Done changed from 30 to 80
Anna has made a prototype website. Not yet publicly visible.
We'll ask the "alpha testers" to see how it works...
#8
Updated by Anna Maria Bigatti over 1 year ago
- Status changed from Resolved to Feedback
- % Done changed from 80 to 90
The page is ready: https://cocoa.dima.unige.it/cocoa/cocoalib/snapshot.shtml.
I have a personal script which calls release-source.sh.
For Anna: clean up the personal script and migrate what's possibile to release-source.sh.
#9
Updated by Anna Maria Bigatti over 1 year ago
- Estimated time set to 6.00 h
#10
Updated by John Abbott about 1 year ago
- Target version changed from CoCoALib-0.99850 to CoCoALib-0.99880