Re: [OpenOCD-devel] New Release

2020-09-03 Thread Xiaofan Chen
On Thu, Sep 3, 2020 at 12:57 AM Connor Lansdale
 wrote:
>
> Hello! Is there a plan or schedule to release the next stable version? It 
> feels like
> it is ready to go and the last official release was some time ago, I'm curious
> what is holding it back. I am happy to help contribute if possible.
>

I guess it is because of the lack of a release engineer to carry out
the formal release. This is a tough year so that it is getting more
difficult for everyone, including open source projects.


-- 
Xiaofan


___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel


[OpenOCD-devel] New Release

2020-09-02 Thread Connor Lansdale
Hello! Is there a plan or schedule to release the next stable version? It feels 
like it is ready to go and the last official release was some time ago, I'm 
curious what is holding it back. I am happy to help contribute if possible.

Thank you,
Connor

___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel


Re: [OpenOCD-devel] New release?

2019-06-06 Thread Antonio Borneo
Tomas

the changes below are listed in the adapter-driver topic only because
are required by the following changes in the same topic.
But they are generic, not linked with the topic itself, and already approved.
I just retested them on top of current master, to avoid other issues.

Would you mind merging them, independently from the adapter-driver topic?
This would simplify my activity to keep this topic aligned with the
coming rebase of the reset topic.

http://openocd.zylin.com/4891
http://openocd.zylin.com/4892
http://openocd.zylin.com/4893
http://openocd.zylin.com/4894
http://openocd.zylin.com/4912
http://openocd.zylin.com/4911

Antonio


___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel


Re: [OpenOCD-devel] New release?

2019-06-05 Thread Steven Stallion via OpenOCD-devel
On Wed, Jun 5, 2019 at 9:09 AM Tomas Vanek via OpenOCD-devel <
openocd-devel@lists.sourceforge.net> wrote:

> On 05.06.2019 16:10, Matthias Welwarsky wrote:
>
>
>
> I don't see SWD multidrop as a candidate for 0.11 so that can wait, but
> the reset framework is right now so utterly borked that the breakage spills
> over into configuration files. Check the R-CarH3 files for bad examples.
>
>
> Neither do I. But the reset framework should be ready for SWD multidrop.
> At least I do not want to redesign it again in the future when SWD
> multidrop gets widely used.
>
>
>
> The adapter rework - not a candidate for 0.11 is it?
>
> I have no strong opinion here. It seems me ready.
>
>
>
> So, without multidrop integration or additional functionality, what is
> needed to get the reset stuff in? I can spend some time in finishing it up.
>
>
> Yes, the time. More time. This is what we all desperately need.
>

Would it be reasonable to compromise and have a stability period for some
number of weeks with only bugfixes being merged? Some of the modules that I
maintain have a habit of breaking from time to time and I'd like to at
least verify that everything is working correctly before the next release
is cut.

Steve
___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel


Re: [OpenOCD-devel] New release?

2019-06-05 Thread Tomas Vanek via OpenOCD-devel

On 05.06.2019 16:10, Matthias Welwarsky wrote:


I don't see SWD multidrop as a candidate for 0.11 so that can wait, 
but the reset framework is right now so utterly borked that the 
breakage spills over into configuration files. Check the R-CarH3 files 
for bad examples.




Neither do I. But the reset framework should be ready for SWD multidrop.
At least I do not want to redesign it again in the future when SWD 
multidrop gets widely used.



The adapter rework - not a candidate for 0.11 is it?


I have no strong opinion here. It seems me ready.

So, without multidrop integration or additional functionality, what is 
needed to get the reset stuff in? I can spend some time in finishing 
it up.




Yes, the time. More time. This is what we all desperately need.


BR,

Matthias

>

> Regards

> Tom

>

>

> ___

> OpenOCD-devel mailing list

> OpenOCD-devel@lists.sourceforge.net

> https://lists.sourceforge.net/lists/listinfo/openocd-devel



___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel


Re: [OpenOCD-devel] New release?

2019-06-05 Thread Antonio Borneo
Of course, I would like to see the adapter-driver series merged in 0.11.
I did not received any negative feedback, I'm just waiting it get
merged to propose the speed improvement patches on top of it.
There is a minor conflict with the reset series, but easy to manage

I would also like to see the reset series merged before 0.11, and I'm
also ready to contribute on it.

For the multidrop, I don't know. Currently it covers FTDI only, maybe
should be split in SWD queuing and SWD multidrop. Plus I still failed
to get proper HW to test it, so I'm not comfortable to add further
comments.

Antonio


___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel


Re: [OpenOCD-devel] New release?

2019-06-05 Thread Matthias Welwarsky
On Mittwoch, 5. Juni 2019 12:23:11 CEST Tomas Vanek via OpenOCD-devel wrote:
> On 11.05.2019 9:47, matth...@welwarsky.de wrote:
> > I think we're more than ripe for a new release, but there's one patch
> > series that I really want to see merged, which is the reset framework
> > stuff Tomas Vanek has done.
> 
> Matthias,
> 
> I'm afraid it is not wise to wait for any particular patch or series.
> As regards the reset framework, it needs more work: the emerging SWD
> multidrop support
> http://openocd.zylin.com/4935 will require per-target setting
> (http://openocd.zylin.com/4280 which I removed from the series to reduce
> complexity after your complaints)


> I'd like to merge Antonio's adapter rework series first and then focus
> back to reset framework.
> 
> Please start the new release process right now or we'll wait forever...

I don't want to.

I don't see SWD multidrop as a candidate for 0.11 so that can wait, but the 
reset 
framework is right now so utterly borked that the breakage spills over into 
configuration 
files. Check the R-CarH3 files for bad examples.

The adapter rework - not a candidate for 0.11 is it?

So, without multidrop integration or additional functionality, what is needed 
to get the 
reset stuff in? I can spend some time in finishing it up.

BR,
Matthias

> 
> Regards
>  Tom
> 
> 
> ___
> OpenOCD-devel mailing list
> OpenOCD-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openocd-devel



___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel


Re: [OpenOCD-devel] New release?

2019-06-05 Thread Tomas Vanek via OpenOCD-devel

On 11.05.2019 9:47, matth...@welwarsky.de wrote:
I think we're more than ripe for a new release, but there's one patch 
series that I really want to see merged, which is the reset framework 
stuff Tomas Vanek has done.


Matthias,

I'm afraid it is not wise to wait for any particular patch or series.
As regards the reset framework, it needs more work: the emerging SWD 
multidrop support

http://openocd.zylin.com/4935 will require per-target setting
(http://openocd.zylin.com/4280 which I removed from the series to reduce 
complexity after your complaints)
I'd like to merge Antonio's adapter rework series first and then focus 
back to reset framework.


Please start the new release process right now or we'll wait forever...

Regards
Tom


___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel


Re: [OpenOCD-devel] New release

2019-05-17 Thread Claudio Lanconelli

Hi Andreas,
does the silicon bug affect F4 and F7 too?
If not, can you split the patch so to merge only F4 & F7 stuff, and H7 & 
L4+ in the new patch you are working on?
I think multiple small patches are better than a big one, and probably 
has more chances to be merged.


Il 15/05/19 15:27, Andreas Bolsch ha scritto:
Please note that I'm currently working on some significant changes as 
H7, L4+ (and apparently MP1) series suffer from an unpleasant silicon 
bug in memory mapped mode ...


On 2019-05-15 14:43, Claudio Lanconelli wrote:

Hello,
can you merge http://openocd.zylin.com/#/c/4321 before next release, 
please.

I don't think I'm the only one who need support to QSPIFlash on
STM32F7 (more than two years old!!!)

Cheers,
Claudio Lanconelli



___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel




--


*Claudio Lanconelli* | Ricerca e Sviluppo


*Eurek s.r.l.* Via Celletta 8/b | 40026 Imola (BO) - Italy | +39 *0542 
609120*
claudiolancone...@eurek.it  | 
www.eurek.it 
___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel


Re: [OpenOCD-devel] New release

2019-05-15 Thread Andreas Bolsch
Please note that I'm currently working on some significant changes as 
H7, L4+ (and apparently MP1) series suffer from an unpleasant silicon 
bug in memory mapped mode ...


On 2019-05-15 14:43, Claudio Lanconelli wrote:

Hello,
can you merge http://openocd.zylin.com/#/c/4321 before next release, 
please.

I don't think I'm the only one who need support to QSPIFlash on
STM32F7 (more than two years old!!!)

Cheers,
Claudio Lanconelli



___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel



___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel


[OpenOCD-devel] New release

2019-05-15 Thread Claudio Lanconelli

Hello,
can you merge http://openocd.zylin.com/#/c/4321 before next release, please.
I don't think I'm the only one who need support to QSPIFlash on STM32F7 
(more than two years old!!!)


Cheers,
Claudio Lanconelli



___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel


Re: [OpenOCD-devel] New release?

2019-05-14 Thread Liviu Ionescu



> On 14 May 2019, at 15:56, Oleksij Rempel  wrote:
> 
> Last digit is used as counter n++, not a day.

to me this looks like an inconsistency; even with a clear and detailed 
documentation, I doubt you can avoid confusion.

that's the beauty of semver, you don't have to define your own semantics, it is 
already defined and the definition is more or less a de facto standard.

using dates has the advantage of telling how old a release is, but can you tell 
if 2019.04 is still compatible with 2018.10? or if it is an enhancement?

anyway, probably anything is better than the current 0.10, 0.11, 0.12...


regards,

Liviu



___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel


Re: [OpenOCD-devel] New release?

2019-05-14 Thread Oleksij Rempel

Am 14.05.19 um 14:41 schrieb Liviu Ionescu:




On 14 May 2019, at 12:40, Oleksij Rempel  wrote:

Or we can use just use year and month of release


if you go that route, be sure you include the day too, otherwise for a buggy 
release issued at the beginning of the month you have to wait till next month 
to release a fix.


In most cases the day is less usable. Some times a bug fix release is needed 
only for this specific
release in a different month or year. Last digit is used as counter n++, not a 
day.

--
Regards,
Oleksij


___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel


Re: [OpenOCD-devel] New release?

2019-05-14 Thread Liviu Ionescu



> On 14 May 2019, at 12:40, Oleksij Rempel  wrote:
> 
> Or we can use just use year and month of release

if you go that route, be sure you include the day too, otherwise for a buggy 
release issued at the beginning of the month you have to wait till next month 
to release a fix.

regards,

Liviu



___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel


Re: [OpenOCD-devel] New release?

2019-05-14 Thread Oleksij Rempel

Am 13.05.19 um 11:35 schrieb Matthias Welwarsky:

On Samstag, 11. Mai 2019 10:50:03 CEST Liviu Ionescu wrote:

 > > On 11 May 2019, at 10:47, matth...@welwarsky.de wrote:

 > >

 > > I think we're more than ripe for a new release,

 >

 > super!

 >

 > > but there's one patch series ... and a few kinks ...

 >

 > sure, I don't think there's a real rush, when you think the code is ready

 > for a new release, just let us know.

 >

 > ---

 >

 > what do you think about making periodic releases and possibly adopting

 > semantic versioning (semver)?

Hm. That has a lot of implications.

I cannot see openocd doing major/minor releases, let alone patches. There is no 
roadmap, no
definition of what major/minor would mean. Given our contribution model, it 
doesn't seem viable.
Contributions will hardly ever match up with features on a roadmap. We just 
have to take what's coming.

Patch releases imply that a "stable" version exists to receive these patches. I 
don't see that
happening. I'm all for increasing the release frequency, though. But a single, 
incremental version
number is IMHO good enough for our release model. What about the next version just being 
"11"
followed be "12" half a year later?

Automatic nightly builds for the supported platforms would be nice and will 
make openocd more
accessible between releases.


I'm ok with it. Or we can use just use year and month of release:
2019.05.0.
It will be easy to recognize how old is the version and make communication on 
IRC even more funny:
2032.03.12 12:12 : hi, my OpenOCD version 1976.02.0 is not working 
properly, can you please
help me?


--
Regards,
Oleksij


___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel


Re: [OpenOCD-devel] New release?

2019-05-13 Thread Liviu Ionescu



> On 13 May 2019, at 12:35, Matthias Welwarsky  wrote:
> 
> > what do you think about making periodic releases and possibly adopting
> > semantic versioning (semver)?
>  
> Hm. That has a lot of implications.
>  
> I cannot see openocd doing major/minor releases, let alone patches. There is 
> no roadmap, no definition of what major/minor would mean. Given our 
> contribution model, it doesn't seem viable. Contributions will hardly ever 
> match up with features on a roadmap. We just have to take what's coming. 
>  
> Patch releases imply that a "stable" version exists to receive these patches. 
> I don't see that happening.

I'm afraid there is a misunderstanding, I'm already using the semantic 
versioning model for other projects and things are not at all that complicated. 

btw, NPM, the node.js repository (https://www.npmjs.com) manages more than 8 
Billions - with B - downloads **per week**, all governed by the semver rules 
and everything works like a charm.

did you read the https://semver.org page?

when making semver releases, there are two really simple questions to ask 
before deciding which number to increase.

1 - does the new version introduce any incompatibilities with the previous 
version? like different behaviour, or removed functionality. if so, increase 
the major version number and reset the minor and patch.

2 - does the new version add any new features or enhanced functionality 
(without breaking compatibility)? like new commands, new scripts, new options, 
etc. if so, keep the major number, increase the minor number and reset the 
patch.

otherwise all changes are bug fixes; keep the major/minor and increase the 
patch.

for those new to the subject, this is the essence of semantic versioning.

---

this approach does not need any roadmap, does not need to redefine the meaning 
of major/minor, does not require any change in the contribution model, nor 
anything special/unusual.

not even the repository needs mandatory changes, although a new branch to 
easily identify the stable from the development content would be helpful.

there are at leat two possible ways for this new branch:

- a new branch like 'develop', and all new contributions switched to that 
branch; when it is time for a release, the 'develop' branch is merged into 
'master'
- a new branch like 'stable', and at release time the merges are from 'master' 
to 'stable'.

in both cases, at release time someone with a good knowledge of the project 
needs to answer the 2 questions above (by inspecting the commit history, for 
example) and to decide the new version number.

2 planned releases per year, like in December and June, plus occasional patch 
releases in case bugs are encountered and fixed, should probably be more than 
enough.


in my opinion things are quite manageable. and the users have the immediate 
benefit of knowing what to expect from a new release.

any other opinions favouring semantic versioning?


regards,

Liviu





___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel


Re: [OpenOCD-devel] New release?

2019-05-13 Thread Matthias Welwarsky
On Samstag, 11. Mai 2019 10:50:03 CEST Liviu Ionescu wrote:
> > On 11 May 2019, at 10:47, matth...@welwarsky.de wrote:
> > 
> > I think we're more than ripe for a new release,
> 
> super!
> 
> > but there's one patch series ... and a few kinks ...
> 
> sure, I don't think there's a real rush, when you think the code is ready
> for a new release, just let us know.
> 
> ---
> 
> what do you think about making periodic releases and possibly adopting
> semantic versioning (semver)?

Hm. That has a lot of implications.

I cannot see openocd doing major/minor releases, let alone patches. There is no 
roadmap, no definition of what major/minor would mean. Given our contribution 
model, 
it doesn't seem viable. Contributions will hardly ever match up with features 
on a 
roadmap. We just have to take what's coming. 

Patch releases imply that a "stable" version exists to receive these patches. I 
don't see 
that happening. I'm all for increasing the release frequency, though. But a 
single, 
incremental version number is IMHO good enough for our release model. What 
about the 
next version just being "11" followed be "12" half a year later?

Automatic nightly builds for the supported platforms would be nice and will 
make 
openocd more accessible between releases.

BR,
Matthias

> 
> 
> regards,
> 
> Liviu
> 
> 
> 
> ___
> OpenOCD-devel mailing list
> OpenOCD-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openocd-devel


___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel


Re: [OpenOCD-devel] New release?

2019-05-11 Thread Liviu Ionescu



> On 11 May 2019, at 10:47, matth...@welwarsky.de wrote:
> 
> I think we're more than ripe for a new release,

super!

> but there's one patch series ... and a few kinks ...

sure, I don't think there's a real rush, when you think the code is ready for a 
new release, just let us know.

---

what do you think about making periodic releases and possibly adopting semantic 
versioning (semver)?


regards,

Liviu



___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel


Re: [OpenOCD-devel] New release?

2019-05-11 Thread matthias
On Mittwoch, 8. Mai 2019 19:32:34 CEST Liviu Ionescu wrote:
> I know that OpenOCD uses a rolling distribution model, with all commits
> being considered stable, but is there any new official release planned?
> 
> 0.10 came in Jan 2017, more than two years ago, and I reached 0.10.0-12 for
> the GNU MCU Eclipse OpenOCD distribution, which is a bit unusual.

I think we're more than ripe for a new release, but there's one patch series 
that I really want to see merged, which is the reset framework stuff Tomas 
Vanek has done. There are only a few minor things to correct, afaict, and then 
we can merge the whole thing.

That, and a few kinks in the hwthread support to be ironed out. There are 
patches already lined up which are more or less ready for inclusion, once I 
get around to check them.

BR,
Matthias

> 
> 
> Regards,
> 
> Liviu
> 
> 
> 
> ___
> OpenOCD-devel mailing list
> OpenOCD-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openocd-devel






___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel


Re: [OpenOCD-devel] New release?

2019-05-09 Thread Daniel Glöckner
On Thu, May 09, 2019 at 03:50:43PM +0200, kristof.mul...@telenet.be wrote:
> 2. http://openocd.net
>This website is apparently offline for the moment. I remember it was a 
> very good-looking
>website. You can visit a snapshot through http://web.archive.org.
>Looking at the (snapshot of) this website, it looks like it belonged to
>"Hochschule Augsburg".

That site was created by the company embedded projects GmbH, which was
managed by Benedikt Sauter of USBprog. Nowadays he appears to focus on
his new company Xentral ERP Software GmbH.

Best regards,

  Daniel



___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel


Re: [OpenOCD-devel] New release?

2019-05-09 Thread kristof . mulier
Hi @OpenOCD developers,

I really like the initiative from Mr. Liviu Ionescu:

 > For a few releases per year I can handle the multi-platform binary 
 > distribution,
 > as I already did. I provide 32/64 Windows, 32/64 Linux, and macOS binaries.

I think it would be great to make these binaries downloadable from the official
OpenOCD website.

Talking about distributing the binaries, what's actually the "official 
website"? I'm a bit
puzzled, because I found two websites:

1. http://openocd.org/
   Looks very basic. I think a nicer website would be great (just my personal 
opinion).

2. http://openocd.net
   This website is apparently offline for the moment. I remember it was a very 
good-looking
   website. You can visit a snapshot through http://web.archive.org.
   Looking at the (snapshot of) this website, it looks like it belonged to
   "Hochschule Augsburg".


Kind greetings,

Kristof




___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel


___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel


Re: [OpenOCD-devel] New release?

2019-05-09 Thread Liviu Ionescu



> On 9 May 2019, at 08:08, Christopher Head  wrote:
> 
> 
> ... Make that three. I think a couple of times a year would be nice, if not
> more often.

Great!

In practical terms, the maintenance overhead is minimal, we only need to add a 
new branch to the repository (like 'develop') and enforce that all 
contributions go that branch. 

>From time to time someone with a good project understanding should evaluate 
>the changes and decide whether they are bug fixes, enhancements or 
>incompatible changes, and increase the version number accordingly; then merge 
>the commits to the master branch and inform the world on the new release (via 
>Twitter, for example).


Regards,

Liviu



___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel


Re: [OpenOCD-devel] New release?

2019-05-09 Thread Liviu Ionescu



> On 9 May 2019, at 10:09, kristof.mul...@telenet.be wrote:
> 
> ... Releases for both Windows and Linux (and why not MacOS) would be great.

for a few releases per year I can handle the multi-platform binary 
distribution, as I already did. I provide 32/64 Windows, 32/64 Linux, and macOS 
binaries.

for more generality I anyway plan to move all binary tools I maintain 
(arm/risc-v toolchains, openocd, qemu, make, etc) outside the GNU MCU Eclipse 
project, and rename them like xPack OpenOCD, xPack QEMU, etc; all of them will 
be available as portable archives, that can be installed manually or via the 
portable tool 'xpm' (the xPack Package Manager - 
https://www.npmjs.com/package/xpm).


regards,

Liviu


p.s. for the Linux package maintainers that may ask 'why a new package 
manager', xPacks are by design not only portable, but multi-version, which 
means it is possible to install several different versions of the same package 
at the same time, and allow each project to use the version it needs, via a 
list of dependencies that are automatically satisfied by 'xpm'. very simple and 
convenient, including in CI environments. 






___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel


Re: [OpenOCD-devel] New release?

2019-05-09 Thread kristof . mulier
Hi,

I agree with Mr. Ionescu and Mr. McDowell.
A few releases per year would be great. Also, the project should no longer 
carry the experimental 0 number. It's a mature and popular software.
Please don't forget the Windows users. Releases for both Windows and Linux (and 
why not MacOS) would be great.

Will the release be downloadable from http://openocd.org/?
Shouldn't the website become a more professional https domain instead of plain 
http?

Kind greetings,

Kristof Mulier



- Oorspronkelijk bericht -
Van: "Liviu Ionescu" 
Aan: "Jonathan McDowell" 
Cc: "openocd-devel" 
Verzonden: Woensdag 8 mei 2019 22:33:44
Onderwerp: Re: [OpenOCD-devel] New release?

> On 8 May 2019, at 23:00, Jonathan McDowell  wrote:
> 
> ... I asked this question back in September and didn't get any responses;

this makes two of us interested in this.

anyone else that would like to have a more active versioning scheme for the 
project?

> I've been pondering whether I should just
> start packaging snapshots instead. 



from a practical point of view, I think that 2-4 minor releases per year would 
be fine, with some of them turned to major releases (that break compatibility), 
when needed.

I also think that the project is mature enough to go past the experimental 0 
major number (according to https://semver.org, which is a proposal that for me  
makes a lot of sense).


regards,

Liviu




___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel


___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel


Re: [OpenOCD-devel] New release?

2019-05-08 Thread Christopher Head
On Wed, 8 May 2019 23:33:44 +0300
Liviu Ionescu  wrote:

> > On 8 May 2019, at 23:00, Jonathan McDowell  wrote:
> > 
> > ... I asked this question back in September and didn't get any
> > responses;  
> 
> this makes two of us interested in this.
> 
> anyone else that would like to have a more active versioning scheme
> for the project?

Make that three. I think a couple of times a year would be nice, if not
more often.
-- 
Christopher Head


pgp5hwoR7W0Tg.pgp
Description: OpenPGP digital signature
___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel


Re: [OpenOCD-devel] New release?

2019-05-08 Thread Liviu Ionescu



> On 8 May 2019, at 23:00, Jonathan McDowell  wrote:
> 
> ... I asked this question back in September and didn't get any responses;

this makes two of us interested in this.

anyone else that would like to have a more active versioning scheme for the 
project?

> I've been pondering whether I should just
> start packaging snapshots instead. 



from a practical point of view, I think that 2-4 minor releases per year would 
be fine, with some of them turned to major releases (that break compatibility), 
when needed.

I also think that the project is mature enough to go past the experimental 0 
major number (according to https://semver.org, which is a proposal that for me  
makes a lot of sense).


regards,

Liviu




___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel


Re: [OpenOCD-devel] New release?

2019-05-08 Thread Jonathan McDowell
On Wed, May 08, 2019 at 08:32:34PM +0300, Liviu Ionescu wrote:
> I know that OpenOCD uses a rolling distribution model, with all
> commits being considered stable, but is there any new official release
> planned? 
> 
> 0.10 came in Jan 2017, more than two years ago, and I reached
> 0.10.0-12 for the GNU MCU Eclipse OpenOCD distribution, which is a bit
> unusual.

I asked this question back in September and didn't get any responses; as
the Debian package maintainer I've been pondering whether I should just
start packaging snapshots instead. The lack of features like aarch64
support in a released version is somewhat painful.

J.

-- 
If I hold really still maybe all of this will just go away.


___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel


[OpenOCD-devel] New release?

2019-05-08 Thread Liviu Ionescu
I know that OpenOCD uses a rolling distribution model, with all commits being 
considered stable, but is there any new official release planned? 

0.10 came in Jan 2017, more than two years ago, and I reached 0.10.0-12 for the 
GNU MCU Eclipse OpenOCD distribution, which is a bit unusual.


Regards,

Liviu



___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel