Roadmap proposal

[Jan]

Hi All!
Following up on the discussion at
https://groups.google.com/g/openpnp/c/tzGGPRAF6Pw/m/SIDPzR1oAwAJ, I'd
like to proposal that we turn the current test version into the next
stable release on February 1st. Up till then, we shall only accept and
merge fixes.
Then we starting merging the many open PRs into the current test
branch. I'd like to keep the name and linkage on the web to encourage as
many as possible to test the features. (Due to the new stable release
there is an option to switch branches in case stability is the primary
focus.) I'd also like to encourage all to participate in reviewing and
commending pending PRS and test new features. All commends are welcome.
As you have read, Niclas is currently taking a new stab to update the
XML parser. If that's in and tested, I'd suggest to create OpenPnP 3.0.
Any concerns or commends?

Jan

[Jason von Nieda]

Sounds good to me! Thank you for taking this on!

Additionally, I want to note that I still read most messages on the list and try to jump in when really needed, but if I miss something that requires my attention please just email me directly at ja...@vonnieda.org.

Jason

-- 

You received this message because you are subscribed to the Google Groups "OpenPnP" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/openpnp/59274f6a-7e2e-4e34-b6d4-98de1ba30750%40googlemail.com.

[Toby Dickenson]

Thank you for taking a lead on this. Your plan sounds good to me.

Here I noted some other tasks that I suggest need doing for this release.

https://groups.google.com/g/openpnp/c/tzGGPRAF6Pw/m/TP5r6ui_CgAJ

To view this discussion visit https://groups.google.com/d/msgid/openpnp/7e03c022-4b17-4e4a-b5f1-a4116a43a121%40app.fastmail.com.

[jbussmann]

Awesome, looking forward to this!

Other things I'm looking forward to:

- improved branch naming (maybe you already imply this) because master, develop and test is certainly one too many of the generically named ones.

- updated API docs and make this page more informative for people unfamiliar with the project, just looking for what to feed into the scripting engine.

- increment version to 2.1 sounds good to me too, though I have no idea where I can find anything other than the build number/hash and the date.

[Jan]

Hi!

On 23.01.2025 10:36, jbussmann wrote:
> Awesome, looking forward to this!
>
> Other things I'm looking forward to:

> - improved <https://github.com/openpnp/openpnp/issues/1661>branch naming

> (maybe you already imply this) because master, develop and test is
> certainly one too many of the generically named ones.

@Jason: how/when can be do that? I'd suggest to keep "test" for new
features that require testing (and to keep all thus uses currently on
the test version where they are) and rename the branch where the stable
version is build from "stable". All the other branches could - IMHO - be
closed.

> - updated API docs and make this <http://openpnp.github.io/openpnp/

> > page more informative for people unfamiliar with the project, just
> looking for what to feed into the scripting engine.

That is - as stated on the that page - build automatically, but not for
the test branch, so likely outdated...
@Jason: can we update that to generate the API for the stable and test
branch?
If you still think - after the rebuild that shall take place as part of
the stable release creation on Feb. 1st - there is room for
improvements, please feel free to prepare a PR and/or ask more specific.
The documentation is embedded into the code and not always updated by
all PRs (as the Changelog).

> - increment version to 2.1 sounds good to me too, though I have no idea
> where I can find anything other than the build number/hash and the date.

If you think there is something that is significantly different from 2.0
and requires the users attention, please feel free to submit a PR. I'm
not aware of anything like that, but that might be "operational
blindness" by someone using the test branch for quite some time.
I actually don't know where the version number is stored and from which
document the welcome screen is created and when it is triggered. We'll
find out if you need help!

Jan

[Jan]

Hi Toby!
Please remind me what changes are still required before making the
current test version the next stable release. I'd say you contributed
the major part by providing a meaningful changelog. I'm willing to
accept cosmetic updated and functional fixes...

Jan

On 23.01.2025 09:13, Toby Dickenson wrote:
> Thank you for taking a lead on this. Your plan sounds good to me.
>
> Here I noted some other tasks that I suggest need doing for this release.
> https://groups.google.com/g/openpnp/c/tzGGPRAF6Pw/m/TP5r6ui_CgAJ
> <https://groups.google.com/g/openpnp/c/tzGGPRAF6Pw/m/TP5r6ui_CgAJ>
>
> On Wed, 22 Jan 2025 at 16:19, Jason von Nieda <ja...@vonnieda.org

> <mailto:ja...@vonnieda.org>> wrote:
>
> __

> Sounds good to me! Thank you for taking this on!
>
> Additionally, I want to note that I still read most messages on the
> list and try to jump in when really needed, but if I miss something
> that requires my attention please just email me directly at

> ja...@vonnieda.org <mailto:ja...@vonnieda.org>.

>
> Jason
>
>
> On Wed, Jan 22, 2025, at 8:14 AM, 'Jan' via OpenPnP wrote:
>> Hi All!
>> Following up on the discussion at
>> https://groups.google.com/g/openpnp/c/tzGGPRAF6Pw/m/SIDPzR1oAwAJ

>> <https://groups.google.com/g/openpnp/c/tzGGPRAF6Pw/m/
>> SIDPzR1oAwAJ>, I'd

>> like to proposal that we turn the current test version into the next
>> stable release on February 1st. Up till then, we shall only accept
>> and
>> merge fixes.
>> Then we starting merging the many open PRs into the current test
>> branch. I'd like to keep the name and linkage on the web to
>> encourage as
>> many as possible to test the features. (Due to the new stable release
>> there is an option to switch branches in case stability is the
>> primary
>> focus.) I'd also like to encourage all to participate in reviewing
>> and
>> commending pending PRS and test new features. All commends are
>> welcome.
>> As you have read, Niclas is currently taking a new stab to update the
>> XML parser. If that's in and tested, I'd suggest to create OpenPnP
>> 3.0.
>> Any concerns or commends?
>>
>> Jan
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "OpenPnP" group.
>> To unsubscribe from this group and stop receiving emails from it,
>> send an email to openpnp+u...@googlegroups.com

>> <mailto:openpnp%2Bunsu...@googlegroups.com>.

>> To view this discussion visit https://groups.google.com/d/msgid/
>> openpnp/59274f6a-7e2e-4e34-b6d4-98de1ba30750%40googlemail.com

>> <https://groups.google.com/d/msgid/openpnp/59274f6a-7e2e-4e34-
>> b6d4-98de1ba30750%40googlemail.com>.

>>
>
> --
> You received this message because you are subscribed to the Google
> Groups "OpenPnP" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to openpnp+u...@googlegroups.com

> <mailto:openpnp+u...@googlegroups.com>.

> To view this discussion visit https://groups.google.com/d/msgid/

> openpnp/7e03c022-4b17-4e4a-b5f1-a4116a43a121%40app.fastmail.com
> <https://groups.google.com/d/msgid/openpnp/7e03c022-4b17-4e4a-b5f1-
> a4116a43a121%40app.fastmail.com?utm_medium=email&utm_source=footer>.

>
> --
> You received this message because you are subscribed to the Google
> Groups "OpenPnP" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to openpnp+u...@googlegroups.com

> <mailto:openpnp+u...@googlegroups.com>.

> To view this discussion visit https://groups.google.com/d/msgid/openpnp/

> CAH35urf_RGmTTWZL773eO%2Bn6R-px7qKDs%2BZauTbAVOftgB3R-w%40mail.gmail.com
> <https://groups.google.com/d/msgid/openpnp/CAH35urf_RGmTTWZL773eO%2Bn6R-
> px7qKDs%2BZauTbAVOftgB3R-w%40mail.gmail.com?
> utm_medium=email&utm_source=footer>.

[Toby Dickenson]

> - increment version to 2.1 sounds good to me too, though I have no idea
> where I can find anything other than the build number/hash and the date.

If you think there is something that is significantly different from 2.0
and requires the users attention, please feel free to submit a PR. I'm
not aware of anything like that, but that might be "operational
blindness" by someone using the test branch for quite some time.

2.0 is the version number of the release from the develop branch which we have been recommending noone use. 2.0 is also the version number of all the test snapshots from the last year.

It will be useful to distinguish this upcoming stable release from that history. Both for technical support reasons, and promoting this stable release to those who have been recommending historic versions.

IMO 2.1 makes sense for this release, and we should be prompt in changing the "test" branch to 2.2 before merging the next feature change for a subsequent release.

 

        I actually don't know where the version number is stored and from which
document the welcome screen is created and when it is triggered. We'll
find out if you need help!

Nor do I, but will aim for a PR this weekend. There are some other cosmetic details like copyright dates that I will aim to sweep up in the one PR.

> Please remind me

The other detail that I know needs to change is https://openpnp.org/downloads/. Both that page, and the files linked.

[jbussmann]

On Saturday, 25 January 2025 at 11:54:06 UTC+1 to...@tarind.com wrote:

2.0 is the version number of the release from the develop branch which we have been recommending noone use. 2.0 is also the version number of all the test snapshots from the last year.

It will be useful to distinguish this upcoming stable release from that history. Both for technical support reasons, and promoting this stable release to those who have been recommending historic versions.

IMO 2.1 makes sense for this release, and we should be prompt in changing the "test" branch to 2.2 before merging the next feature change for a subsequent release.

Exactly my thoughts, I could not have said it better. Also, coming from the Opulo camp, it appears that at least some people there think that OpenPnP has been totally buggy and unstable for the last 3 or so years years because there was no official release. By not seeing the whole picture I fully understand everyone who is hesitant to use a test build for production. Bumping the version number surely helps with accepting that this is a proper and stable version, not just a buggy release from the test branch, for the sake of having one.

Furthermore, Mark convinced me that Issues & Solutions is the way to go and I'm in the process of creating a clean machine.xml from scratch for my LumenPnP with only machine settings and no calibration data. Initially I planned to do this just for the sake of it and maybe share with other LumenPnP users who would like to give Issues & Solutions a try, so they can start out with a minimal config and right away target the vision and calibration milestones. Meanwhile it seems Opulo is also interested and willing to give Issues & Solutions a shot. With a release around the corner that isn't just another 2.0 I'm optimistic they might go this route.

[Jan]

Hi Toby!

On 25.01.2025 11:53, Toby Dickenson wrote:
[...]

> Nor do I, but will aim for a PR this weekend. There are some other
> cosmetic details like copyright dates that I will aim to sweep up in the
> one PR.
>

Thank You!

> > Please remind me
>
> The other detail that I know needs to change is https://openpnp.org/

> downloads/ <https://openpnp.org/downloads/>. Both that page, and the
> files linked.
>
For the test builds this is done automatically. For release builds I do
not yet know. Likely we just have to merge test to development and this
might triggers the build and rebuild of the API. I hope Jason will
clarify that soon.

Jan

[Jan]

Hi jbussmann!

On 25.01.2025 18:38, jbussmann wrote:
[...]

> Exactly my thoughts, I could not have said it better. Also, coming from
> the Opulo camp, it appears that at least some people there think that
> OpenPnP has been totally buggy and unstable for the last 3 or so years
> years because there was no official release. By not seeing the whole
> picture I fully understand everyone who is hesitant to use a test build
> for production. Bumping the version number surely helps with accepting
> that this is a proper and stable version, not just a buggy release from
> the test branch, for the sake of having one.
>

Ok, lets change the version number. Remains the question where it can be
seen. At least with the updated changelog the progress is obvious.

> Furthermore, Mark convinced me that Issues & Solutions is the way to go
> and I'm in the process of creating a clean machine.xml from scratch for
> my LumenPnP with only machine settings and no calibration data.
> Initially I planned to do this just for the sake of it and maybe share
> with other LumenPnP users who would like to give Issues & Solutions a
> try, so they can start out with a minimal config and right away target
> the vision and calibration milestones. Meanwhile it seems Opulo is also
> interested and willing to give Issues & Solutions a shot. With a release
> around the corner that isn't just another 2.0 I'm optimistic they might
> go this route.
>

That's good to hear!
I'm thinking about a switch in the machine.xml for quite some time,
that - if set - resets all solutions, we consider non-portable like
backlash and camera calibration. Before you spend a lot of time creating
a special machine.xml, would to mind, implementing that? My idea was to
add a global manufactorerSuppliedFile flag to Issues & Solutions which
defaults to false and evaluate it after loading the machine.xml. If
true, reset all solutions that are NOT marked as portable. This way we
might reset more solutions then needed but new solutions would initially
be considered non-portable.
With such a flag anyone could make a simple modification in the
machine.xml and provide a file that is safe to use (and causes low
support calls) for everyone.

Jan

[jbussmann]

On Saturday, 25 January 2025 at 23:11:10 UTC+1 Jan wrote:

That's good to hear!
I'm thinking about a switch in the machine.xml for quite some time,
that - if set - resets all solutions, we consider non-portable like
backlash and camera calibration. Before you spend a lot of time creating
a special machine.xml, would to mind, implementing that? My idea was to
add a global manufactorerSuppliedFile flag to Issues & Solutions which
defaults to false and evaluate it after loading the machine.xml. If
true, reset all solutions that are NOT marked as portable. This way we
might reset more solutions then needed but new solutions would initially
be considered non-portable.
With such a flag anyone could make a simple modification in the
machine.xml and provide a file that is safe to use (and causes low
support calls) for everyone.

There are some thoughts I would like to share on this topic. While I really like this idea, when you brought it up recently you also mentioned it's fatal flaw: only a few people will know this flag exits and most manufacturers will therefore simply overlook it. Unless we somehow make it a very prominent feature to eg. "Save config as template" but even then, I expect most to just grab the xml file anyway, because this is what they always did.

Ideally, there would be a way do uniquely identify each machine in software and if another machine is detected, the calibration is reset. I think a unique USB identifier would be useful but still flawed and I don't think this is implemented in all of the common controller boards to begin with. Another way might be to save the M115 response, the OpenPnP build number and some PC/OS/UEFI serial number (or better hashers thereof). If anyone of those is detected to have changed, the user is presented with a "Setup was changed" dialog with some explanation why this shows up and the option to choose if this config file is originally from this machine or if it was imported from elsewhere. Unfortunately this will produce almost exclusively false positives but since they happen rather rarely I think this is acceptable. In the case when the build number changes, this mechanism would also serve as a platform to inform the user about potential backwards compatibility issues.

I would gladly implement something like this. However it's only a few weeks since I startet to learn about the inner workings of OpenPnP and even less since I started to care about Issues & Solutions. I have virtually no clue, what settings/solutions are considered portable and even less so what settings/solutions there are to begin with. Thus I think spending a lot of time exploring Issues & Solutions and learning how the machine.xml is build up is exactly what I need right now. Furthermore, while I can program, I wouldn't call myself a good programmer and the little Java knowledge I once had, practically faded out of existence. Therefore, contributing code is far out of reach at the moment. I guess I'm punching a bit above my weight around here, sorry for that. 

[Jan]

Ok, I don't see, that we can get a UUID from the controller to uniquely
identify it unless there is an option in GCode to eg. store/recall it.
So why not implement all this together: the flag, a Save-as-Template
option and a detection if the PC has changed (I assume that Java
supports something like a system id). Then we can reopen some solutions
if the flag is set or if the system id has changed (likely with a
confirmation box.)

> I would gladly implement something like this. However it's only a few
> weeks since I startet to learn about the inner workings of OpenPnP and
> even less since I started to care about Issues & Solutions. I have
> virtually no clue, what settings/solutions are considered portable and
> even less so what settings/solutions there are to begin with. Thus I
> think spending a lot of time exploring Issues & Solutions and learning
> how the machine.xml is build up is exactly what I need right now.
> Furthermore, while I can program, I wouldn't call myself a good
> programmer and the little Java knowledge I once had, practically faded
> out of existence. Therefore, contributing code is far out of reach at
> the moment. I guess I'm punching a bit above my weight around here,
> sorry for that.
>

Me to. I jumped in by modifying existing and studding others code. That
when surprisingly well. This project is likely a good starting point, as
I would modify the constructor of Issues & Solutions to force all
solutions to be revisited... Anyhow, someone like you would be - IMHO -
the perfect candidate as you can debug and promote it and assess user
feedback first hand. What ever you decide, I will promote this idea as
I'm convinced it well free up valuable support resources, probably not
immediately, but medium-term.

Jan

[Jason von Nieda]

@Jason: how/when can be do that? I'd suggest to keep "test" for new 

features that require testing (and to keep all thus uses currently on 

the test version where they are) and rename the branch where the stable 

version is build from "stable". All the other branches could - IMHO - be 

closed.

I can make this change whenever you all are ready. We'll want to make sure there are no major PRs targeting develop or master as these will change. Specifically, I will tag master as it stands now, delete it, rename develop to main, and then update the various scripts and infra. After the changes we will have main and test.

> - updated API docs and make this <http://openpnp.github.io/openpnp/ 

>  > page more informative for people unfamiliar with the project, just 

> looking for what to feed into the scripting engine.

That is - as stated on the that page - build automatically, but not for 

the test branch, so likely outdated...

@Jason: can we update that to generate the API for the stable and test 

branch?

Yes, I'll look into this with the above changes. The doc generation got broken a while back so it's out of date across the board: https://github.com/openpnp/openpnp/blob/test/.github/workflows/build_and_deploy.yml#L71

I'll see if I can fix it and switch the branches.

Jason

[Toby Dickenson]

On Sat, 25 Jan 2025 at 22:03, 'Jan' via OpenPnP
<ope...@googlegroups.com> wrote:
>
> Hi Toby!
>
> On 25.01.2025 11:53, Toby Dickenson wrote:
> [...]
> > Nor do I, but will aim for a PR this weekend. There are some other
> > cosmetic details like copyright dates that I will aim to sweep up in the
> > one PR.
> >
> Thank You!

https://github.com/openpnp/openpnp/pull/1732 is ready. It would be
great to have another developer review before merging. Not because it
is complicated, but because we are so close to the release date.

Toby

[Jan]

Hi Jason!

On 27.01.2025 19:27, Jason von Nieda wrote:
>
>>
>> @Jason: how/when can be do that? I'd suggest to keep "test" for new
>> features that require testing (and to keep all thus uses currently on
>> the test version where they are) and rename the branch where the stable
>> version is build from "stable". All the other branches could - IMHO - be
>> closed.
>
> I can make this change whenever you all are ready. We'll want to make
> sure there are no major PRs targeting develop or master as these will
> change. Specifically, I will tag master as it stands now, delete it,
> rename develop to main, and then update the various scripts and infra.
> After the changes we will have main and test.
>

That's very much appreciated. I personally think, it could be done
immediately and should be done before the next stable release so that
the linkage between release and source is up-to-date. I'm not aware of
any pending PRs targetting development.
Please also update the default branch to test. So that all new PRs
target test per default.

Jan

[Toby Dickenson]

Hi all,

> On 27.01.2025 19:27, Jason von Nieda wrote:
> > Specifically, I will tag master as it stands now, delete it,
> > rename develop to main, and then update the various scripts and infra.
> > After the changes we will have main and test.

I have an alternative suggestion. The current 'develop' branch has
some changes not in 'test'. They are changes we dont need, are long
forgotten, and they make any merge from 'test' into 'develop'
non-trivial. Not necessarily difficult, but non-trivial. I suggest it
is better to create a new branch 'main' from 'test' as it stands
today, and the old 'develop' gets tagged and deleted too.

[Jan]

I'm not against you suggestion, but I don't see the need. According to
the logs, Mark cherry-picked two fixes he added to test. This means,
they are the same in both branches. And according to github, test can be
merged without conflicts into development. What non-trivial-to-merge
changes do I miss?

Jan

[Toby Dickenson]

> I'm not against you suggestion, but I don't see the need. According to
> the logs, Mark cherry-picked two fixes he added to test. This means,
> they are the same in both branches. And according to github, test can be
> merged without conflicts into development. What non-trivial-to-merge
> changes do I miss?

I guess I have a higher level of paranoia about any change this close
to a release.

[Jan]

Hi Toby!

I'd suggest to keep as much of the history as possible, hence my objection.
Please explain your objection against merging test to development.
Maybe I've not checked enough to see them myself or have not read you
commends well enough... Lets try to find an agreement before the deadline.

Jan

[Toby Dickenson]

>  Please explain your objection against merging test to development.

> Maybe I've not checked enough to see them myself or have not read you

> commends well enough... Lets try to find an agreement before the deadline.

My objection was based on the observation that currently 'develop' is not an ancestor of 'test'. There are commits in 'develop' not present in the 'test' branch that has seen lots of beta testing. Your plan would allow those commits to "bypass" the beta test process.

But, on review, I see that those commits are useful and low risk. So I propose merging "develop" into "test" today.

Then my objection to your plan disappears, because 'develop' will be an ancestor of 'test' at the point you do the release.

Toby

On Thu, 30 Jan 2025 at 12:05, 'Jan' via OpenPnP <ope...@googlegroups.com> wrote:

Hi Toby!

On 29.01.2025 11:10, Toby Dickenson wrote:
>> I'm not against you suggestion, but I don't see the need. According to
>> the logs, Mark cherry-picked two fixes he added to test. This means,
>> they are the same in both branches. And according to github, test can be
>> merged without conflicts into development. What non-trivial-to-merge
>> changes do I miss?
>
> I guess I have a higher level of paranoia about any change this close
> to a release.
>
I'd suggest to keep as much of the history as possible, hence my objection.

        Jan

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/openpnp/c6650c3d-1bad-464b-a62d-c5b0e9418fe2%40googlemail.com.

[Jan]

Hi Toby!

On 30.01.2025 20:37, Toby Dickenson wrote:
> >  Please explain your objection against merging test to development.
> > Maybe I've not checked enough to see them myself or have not read you
> > commends well enough... Lets try to find an agreement before the
> deadline.
>
> My objection was based on the observation that currently 'develop' is
> not an ancestor of 'test'. There are commits in 'develop' not present in
> the 'test' branch that has seen lots of beta testing. Your plan would
> allow those commits to "bypass" the beta test process.
>
> But, on review, I see that those commits are useful and low risk. So I
> propose merging "develop" into "test" today.

I'm sorry, I don't see them. According to
https://github.com/openpnp/openpnp/compare/test...develop both branches
are in relationship and there are only changes in the FUNDING.yml and
SPONSORS.md, which we may merge back into test. (I don't know if it's on
purpose that thous changes are only in the development branch, Jason
might confirm that). The other commits do not generate any code, so they
are present on both branches.

> Then my objection to your plan disappears, because 'develop' will be an
> ancestor of 'test' at the point you do the release.

Good! So we stick with the plan to create the next stable release on
Feb. 1st.
Thank you for your help!

Jan

> On Thu, 30 Jan 2025 at 12:05, 'Jan' via OpenPnP
> <ope...@googlegroups.com <mailto:ope...@googlegroups.com>> wrote:
>
> Hi Toby!
>
> On 29.01.2025 11:10, Toby Dickenson wrote:
> >> I'm not against you suggestion, but I don't see the need.
> According to
> >> the logs, Mark cherry-picked two fixes he added to test. This means,
> >> they are the same in both branches. And according to github,
> test can be
> >> merged without conflicts into development. What non-trivial-to-merge
> >> changes do I miss?
> >
> > I guess I have a higher level of paranoia about any change this close
> > to a release.
> >
> I'd suggest to keep as much of the history as possible, hence my
> objection.
>
>         Jan
>
> --
> You received this message because you are subscribed to the Google
> Groups "OpenPnP" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to openpnp+u...@googlegroups.com

> <mailto:openpnp%2Bunsu...@googlegroups.com>.

> To view this discussion visit https://groups.google.com/d/msgid/
> openpnp/c6650c3d-1bad-464b-a62d-c5b0e9418fe2%40googlemail.com

> <https://groups.google.com/d/msgid/openpnp/c6650c3d-1bad-464b-a62d-
> c5b0e9418fe2%40googlemail.com>.

>
> --
> You received this message because you are subscribed to the Google
> Groups "OpenPnP" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to openpnp+u...@googlegroups.com

> <mailto:openpnp+u...@googlegroups.com>.

> To view this discussion visit https://groups.google.com/d/msgid/openpnp/

> CAH35ure40RAvayAMVcNCiXrxdEW041p7vWE7%3DWgP7v9D8f-MAA%40mail.gmail.com
> <https://groups.google.com/d/msgid/openpnp/
> CAH35ure40RAvayAMVcNCiXrxdEW041p7vWE7%3DWgP7v9D8f-MAA%40mail.gmail.com?
> utm_medium=email&utm_source=footer>.

[Jan]

Hi Jason!

On 27.01.2025 19:27, Jason von Nieda wrote:

[...]

> I can make this change whenever you all are ready. We'll want to make
> sure there are no major PRs targeting develop or master as these will
> change. Specifically, I will tag master as it stands now, delete it,
> rename develop to main, and then update the various scripts and infra.
> After the changes we will have main and test.
>

Please do it, when ever you have time. There are no pending PRs on
development.
Please also have a look at the download page. It says "OpenPnP 2.0". As
the current stable release is 2.2, it might be worth reflecting it.
IIRC its a known issue, that the 32bit installer requires an external
JVM. This should be IMHO mentioned on the download page.

[...]

> Yes, I'll look into this with the above changes. The doc generation got
> broken a while back so it's out of date across the board: https://
> github.com/openpnp/openpnp/blob/test/.github/workflows/

> build_and_deploy.yml#L71 <https://github.com/openpnp/openpnp/blob/
> test/.github/workflows/build_and_deploy.yml#L71>

> I'll see if I can fix it and switch the branches.
>

That would be nice!
Thank You!

Jan

[Jason von Nieda]

Okay, this is all done. Please take a look and let me know if you see any issues.

I'll comment on the auto updates in the release thread in a moment.

- Branch master tagged as "v1-archive" and deleted.

- Branch develop renamed to main. This changes the default branch name for the repo, so please update your local copies. See the image below for instructions.

- Changed Github actions script to target deploy for main and test, removing develop and master.

- Fixed Javadoc generation in Github Actions.

- Updated docs index to show Main and Test: http://openpnp.github.io/openpnp/.

- Downloads pages updated to show Main and Test only: https://openpnp.org/downloads/

Thanks,

Jason

-- 

You received this message because you are subscribed to the Google Groups "OpenPnP" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/openpnp/60300b53-1b7e-4f0f-8e3a-a03f4f0cf3d0%40googlemail.com.