Hi all
Thanks to Bill for the reminder and good advice about committing an SVN
Tag for our released Version 1.3, r3673. I have now done so.
Bill, any time you're ready to do so, feel free to commit your new setup
and rig-control code. Subsequent development (of what will be v1.4, or
2.0, or whatever) should continue to take place in the
.../branches/wsjtx directory.
If necessary, any bug fix or minor tweak to v1.3 should be done in the
newly created .../tags/wsjtx-1.3 branch. (But this should be resisted,
if possible.) New work should definitely go into .../branches/wsjtx.
How best to handle documentation revisions? They are still very much in
progress, even for Version 1.3.
I suggest that doc revisions should continue to be committed to
.../branches/wsjtx, the development branch, until version 1.4 (or 2.0?)
becomes usable as a beta release. Then we can put a new snapshot of
docs into the .../tags/wsjtx-1.3 branch, and start making further
documentation changes -- in particular, things that will be different in
v1.3 and v1.4 -- in the development branch.
Does this make sense? Is there a better way?
-- Joe, K1JT
When V1.3 users call up the online documentation, they now see the stuff
I committed this morning, r3684. I could
I think that means we should right now start committing documentation
changes to the .../tags/wsjtx-1.3 branch,
As soon as the main development branch starts to have features that
conflict with the present User's Guide -- for example, a Setup |
Configuration screen that looks different -- we'
On 1/31/2014 4:45 PM, Bill Somerville wrote:
On 31/01/2014 20:50, Joe Taylor wrote:
Hi Joe,
John --
John Nelson wrote:
I have downloaded r3673 and it is running undertest - but I notice
you have made improvements regarding Type 1 and 2 messages and
genStdMsgs() - but this is r3677.
Do want these improvements to be excluded from the new release?
I agree it seems slightly awkward, but I decided this morning to
release the well-tested code (r3673) and then make the mods for
auto-generation of messages with complex callsigns. So yes, I'm
recommending that the released version be 3673.
It is best practice to tag milestones like releases in the repo. For
example the command (assuming you use ssh access to the repo):
svn copy -r 3673
svn+ssh://[email protected]/svnroot/repos/wsjt/branches/wsjtx
svn+ssh://[email protected]/svnroot/repos/wsjt/tags/wsjtx-1.3 -m
"Tagging WSJT-X release version"
will tag r3673 for ever more as the 1.3 release of WSJT-X.
That way there is no need to remember which revision represents a
milestone and later defect fix release branches can be created by
copying the tag back to 'branches'.
svn copy is cheap in that no actual files are copied on the server, only
changes to files use 'file space'.
More complex tags can be created if required, for example the discussion
on kvasd binaries is relevant in that the revisions of kvasd used for
the release could also be included in the tag by using the more
comprehensive "build a workspace from various revisions and tag the
workspace contents" version of svn copy. Having said that the
svn:externals property is a much better way of handling mapping of
external files from elsewhere in a repo to a tree in a repo and would
suit the kvasd situation where the binaries are used in multiple projects.
-- Joe
73
Bill
G4WJS.
_______________________________________________
Wsjt-devel mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/wsjt-devel
_______________________________________________
Wsjt-devel mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/wsjt-devel
