Jump to content
Latest News: (loading..)

Recommended Posts

Completed test.

- Generate upload directory and put the files provided in the .json  [Done!]
- Check possible JSON errors before parsing and return message to uploader when has error. [Done!]
- Check possible File Upload errors and return message to uploader when has error. [Done!]


To do:
- Scan the uploaded files for viruses.
- Put the .json data to it's corresponding db fields.

- Do all the same again for the change-log's.

- Bootstrap 4 the reviews section.
- Setup server.

Share this post


Link to post
Share on other sites
4 minutes ago, wHiTeHaT said:

implemented markdown for the change-log.
Be prepared: https://www.markdowntutorial.com/

Is that the same as github?


For a new install or if your store isn't mobile-friendly, get the community-supported responsive osCommerce here: https://github.com/gburton/osCommerce-234-bootstrap/archive/master.zip

 

For Github users: Bootstrap addons - one per branch - https://github.com/BrockleyJohn/Responsive-osCommerce/wiki/Overview-of-Branches

Working on generalising bespoke solutions for Quickbooks integration, Easify integration and pay4later (DEKO) integration at 2.3.x

Share this post


Link to post
Share on other sites
3 minutes ago, wHiTeHaT said:

To keep or not to keep older releases ..... that's the question!

Sometimes - leave it up to the developer to say whether it replaces the previous version (eg internal bugfix) or has other requirements (core code changes, dependencies on other things) that may prevent installing the latest version and you may need an earlier version.


For a new install or if your store isn't mobile-friendly, get the community-supported responsive osCommerce here: https://github.com/gburton/osCommerce-234-bootstrap/archive/master.zip

 

For Github users: Bootstrap addons - one per branch - https://github.com/BrockleyJohn/Responsive-osCommerce/wiki/Overview-of-Branches

Working on generalising bespoke solutions for Quickbooks integration, Easify integration and pay4later (DEKO) integration at 2.3.x

Share this post


Link to post
Share on other sites

A little more on-topic.
did some research on how to "correctly" versioning.
At the end, it not matter, as long as it is "clearly" communicated.
So from this point of writing for apps:
i will allow 3 sections as :
Major.Minor.Patch
Patches should work on all installs.
Minors should be backwards compatible
Major means "brand new", and is not backwards compatible (in theory).

I try to explain further in my best understanding.
Shop-owner runs on 2.3.4.1 CE
Shop-owner installs add-on 1.3.4.1
New version comes: 1.3.9.9 (all shop-owners systems based on 2.3.4.1 CE should be working with that version)

Dev go makes a 1.4.0
There can be shop-owners that can get in trouble with that version, so they should be able to "roll-back"  to 1.3.9.9


(in theory you are always able to roll-back, yet... if the add-on makes drastic changes to the db tables or fileSystem, manual edits/actions might be required,  that is the reason i previously mentioned if must keep the historical releases available for the audience).

So now we have a minor: 1.4.0
Same story.............

When dev comes with a 2.0.0, shop-owner in theory cannot roll-back.
Same story............... 
--------------------------------------------------------------------------------------------------------------------------
That's the "simple explanation".....

Now it comes, compatible with:

compatible : ~2.3.4.1  (not CE)   <--- this means EQUALS TO......
or
compatible : <= 2.3.4.1  CE  <--- This means Smaller or IS
or
compatible  >= 2.2MS2  <--- This means Higher or IS (woop woop... 2.2MS2 on steroids, 10000+ for an add-on like that lol. [but not unlikely]).
-----------------------------------------------------------------------------------------------------------------------

Developer should try to be compatible with he most recent version.
If the dev decide it is time for a major version his end... that is completely fine.

When there will be a "new" Major or Minor or might even a patch.
It is up to the dev to stay compatible or not.
This can be marked with the 
compatible field.

Edited by wHiTeHaT

Share this post


Link to post
Share on other sites

we could also use this idea on other carts too

ie something that can tell us if a module is up to date with latest verion and if module gets to old send writer an email that its time to update or else it will be removed

as a user i'm tired of looking through search results that has not been updated in 10+ years and where the version for the module is made for is covered in a ton of dust

Edited by boelle

Quo plus habent, eo plus cupiunt

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×