Bump major release number after internals change

[cederom]

Hey @flit :-) I can see that a lot of internal changes took place recently in pyOCD along with helper scripts and program usage. I would highly suggest to rename 0.30 (or the first number with that major internal reorganization) and bump major release number to mark API change (i.e. 1.0). This was also somehow reported here: https://github.com/pyocd/pyOCD/issues/1137 by @pfalcon as backward compatibility and package management issues. I can see the problem myself now.

[flit]

Howdy 😄

I feel your pain. I've definitely been thinking about bumping to 1.0 straightaway so I can start incrementing the major version on incompatible changes. The reasons I haven't yet are: previously it was stated that all the deprecated pyocd-* tools would be removed when version 1.0 was reached; #668 defined a number of changes to be made to the Python API before 1.0.

How about I try to quickly complete the majority of the renaming based tasks in #668, and release a 1.0?

Also under consideration is moving to a more flexible revision management scheme, with main and develop branches. This will allow separating work on incompatible changes onto the develop branch. Changing branch usage could be a little disruptive though.

[cederom]

Yo Yo @flit :sunglasses:

That sounds perfect! I also usually use two branches master and devel to have stable and development release for testing - all development goes to devel and when things are tested they are just rebased/merged/pulled to master :-)

I guess when 1.0 comes out it would be also good to mark 0.30+ (or whenever API and tools changed) broken/invalid so package managers will know that (for instance) 0.29 was the last compatible one from 0 major number and they will be able to create separate 1.0+ packages..? Also conflict between 0.X and 1.X will have to be marked..? :-)

Thank you! Have a great weekend! :-) :surfer: