On 26/09/2014 00:03, KI7MT wrote:
> Hi Joe, Bill,
Hi Greg,
>
> I just want to make sure I understand all this now. If we use the
> standard branch head for WSJTX, that is now being called wsjtx v1.5?
Yes, actually wsjtx-1.5.0-rc1.
>
> And to pull WSJTX-1.4.0-RC1, we use:
>
> svn co https://svn.code.sf.net/p/wsjt/wsjt/tags/wsjtx-1.4.0-rc1
Yes, this is the set in stone never to change record of what made RC1.
Probably the only people who would check this out are those who want to
build RC1 kits. It also serves as a label for diffs if you wanted to see
what has changed since RC1.
>
> or
>
> svn co https://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx-1.4
>
> ?
This is where you would check in bug fixes for RC1 i.e. steps toward
RC2, RC3, ... and the actual release of v1.4.0.
Any bug fixes put here would normally (probably always) be merged into
branches/wsjtx so that they get into v1.5 and later as well.
If there is an RC2 etc. this branch is what will get tagged to record
them as well.
If we decide to release v1.4.0 and then find we need to make a new
release before v1.5 is ready then we might branch again from the v1.4 as
v1.4.1, but as we don't promise any support for old versions we would
probably simply tag the v1.4 branch as v1.4.1-rc1 and keep the history
of v1.4.x linear.
A developer who is expecting to provide bugfixes for v1.4 as well as
work on v1.5 would normally have two r/w svn source trees, one in the
main line and one in the branch v1.4. You can do clever tricks with 'svn
switch' and a single source tree but it's a bit complicated and IMHO two
trees is easiest for a small project like WSJT-X.
If you don't intend to contribute to v1.4 then just carrying on with the
branches/wsjtx (the main line) is fine - i.e. do nothing differently
from before the branch existed.
I hope that helps, it gets very complicated quickly with branching so
"less is more" generally. The big pay off is that v1.5 new features can
progress without impacting the v1.4.0 release which may take a few
week/months to hit stability.
As for the docs, they are not within the scope of the branch or v1.4.0
tags so they continue on a linear history. I guess we will tag them too
at the point of the last v1.4.0 build so we know what we made the
release with FWIW.
> 73's
> Greg, KI7MT
73
Bill
G4WJS.
>
>
> On 9/25/2014 21:11, Bill Somerville wrote:
>> On 25/09/2014 21:57, Joe Taylor wrote:
>>> Hi Bill,
>> Hi Joe,
>>> Thanks for posting a clear statement of correct repository procedures
>>> going forward.
>>>
>>> All seems OK to me, except possibly for your parenthetical statement
>>> "one day we really need to move this to trunk".
>>> We can't do this unless we give up the notion that WSJT, MAP65, WSPR,
>>> WSPR-X, and WSJT-X are all part of the same "project". Historically,
>>> the "trunk: of the project is WSJT.
>> Not a problem. Multi project repos usually have
>> project1/{trunk,branches,tags} project2/{trunk,branches,tags} etc..
>>
>> The reason it is important is that most other source control systems
>> have much stronger concepts for branches and tags and moving to them
>> while maintaining all history is normally supported with tools if you
>> have a conventional repo layout.
>>
>> It's not critical or urgent but an example use case is my situation. I
>> use git-svn because it gives me lots of excellent git features while
>> working with svn but because of our repo layout I can't easily have two
>> projects checked out at once because it expects everything to reside in
>> the trunk with only branches and tags in their respective locations. For
>> example if I want to build the docs I have to switch my working tree to
>> docs, another branch, which hides the branch I was on 'wsjtx' while I'm
>> there. This is the main reason that I don't edit the docs or contribute
>> to other JT projects as it is so painful to coerce git-svn to bend the
>> standard layout rules.
>>> -- Joe, K1JT
>>>
>> 73
>> Bill
>> G4WJS.
>>
>> ------------------------------------------------------------------------------
>> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
>> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
>> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
>> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
>> _______________________________________________
>> wsjt-devel mailing list
>> wsjt-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>
------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
